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ABSTRACT 

For the past three decades, the Department of Defense (DoD) has used the U.S. 
Message Text Format (USMTF) as the primary means to exchange information and to 
achieve interoperability between joint and coalition forces. To more effectively exchange 
and share data, the Defense Information Systems Agency (DISA), the lead agency for the 
USMTF, is actively engaged in extending the USMTF standard with a new data sharing 
technology called Extensible Markup Language (XML). This work translates and 
synthesizes Air Tasking Order (ATO) data messages written in XML into a three- 
dimensional (3D) air attack plan within a virtual environment through the use of the 
Virtual Reality Modeling Language (VRML). 
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EXECUTIVE SUMMARY 



The U.S. Message Text Format (USMTF) has served as the vehicle for 
interoperability for the Department of Defense’s (DOD’s) messaging system. While the 
USMTF program has been successful since the 1970’s, its useful life is coming to end 
due to the development of the Extensible Markup Language (XML). The Extensible 
Markup Language has the potential to enable data and systems interoperability for DOD 
and revolutionize the way data is structured, processed, and displayed. 

Unlike USMTF, which can only send the text of a message, XML allows users to 
create messages that contain metadata. Metadata is data that describes information. The 
utilization of metadata is powerful because it provides the consumers of information the 
ability to transform, organize, and render data in ways that suits their needs. 

Realizing XML’s power and advantages, the Defense Information Systems 
Agency, along with other DOD organizations, is looking to XML as a replacement for 
USMTF. In this regard, DISA has sponsored a new group, the XML-MTF Development 
Team, to develop a specification and software tools that transform messages between the 
USMTF and the XML-MTF standards. 

At same time XML was evolving, a new computer animation language, called 
Virtual Reality Modeling Language (VRML), was being developed. The Virtual Reality 
Modeling Language (VRML) is a non -proprietary, international standard for describing 
virtual objects and worlds over networks. VRML is capable of representing three- 
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dimensional (3D) animated objects and multimedia objects with hyperlinks to other 
media such as text, sounds, movies, and images. 

This thesis leverages off the work of the XML-MTF Development Team and the 
Virtual Reality Modeling Language. The goal is to synthesize an air plan from a series of 
XML documents and render it in a three-dimensional world. To achieve this goal, an 
XML ATO, based on the XML-MTF Air Tasking Order DTD, was created. 

To convert an XML ATO into a VRML world, the XML ATO is put through a 
series of transformations. These transformations create new modularized XML 
documents, the most important of which are partial unit flight plans. Partial unit flight 
plans are made into final unit flight plans by adding a unit’s detailed flight missions. 

Each unit’s final plans, along with threat data, are combined into a single XML document 
called the Master Operation Document (MOD). The final step is translating the MOD 
into VRML source code capable of animating an ATO in a virtual world. 

The VRML code produced is modular. The code calls upon a group of VRML 
objects that are filed away like a stack of library books. These objects are called 
PROTOs, which is short for prototype. The PROTOs supply the interface between the 
ATO VRML code and a detailed set VRML code that describes virtual models and 
behaviors such as flying aircraft. The PROTOS offer code modularity that permits the 
ATO VRML code to reference complex virtual objects by name. This allows the ATO 
VRML code to remain simple thus straightforward to auto-generate and maintain. 

The end result is an intricate three-dimensional (3D) world populated with 
aircraft, terrain, and target models. The virtual world permits the viewer to navigate from 
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a high point that gives a map view of the ATO all the way down to flying behind an 
aircraft to see how it interacts with the terrain, targets, and other aircraft. The virtual 
world is the culmination of the power of XML to provide structured, well-formed data 
that can be transformed to any visual format. 



I. INTRODUCTION 



A. OVERVIEW 

The U.S. Message Text Format (USMTF) has served as a vehicle for joint 
warfighting interoperability since the 1970’s. While the USMTF program has been 
successful since its inception, its useful life is coming to end due to the development of 
the Extensible Markup Language (XML). The Extensible Markup Language has the 
potential to enable data and systems interoperability for DOD and revolutionize the way 
data is structured, processed, and displayed. 

Unlike USMTF, which can only send the text of a message, XML allows users to 
create messages that contain metadata. Metadata is data that describes information. The 
utilization of metadata is powerful because it provides the consumers of information the 
ability to transform, organize, and render data in a way that suits their needs. 

This thesis seeks to translate and synthesize USMTF-based Air Tasking Order 
(ATO) data messages written in XML into a three-dimensional (3D) air attack plan 
within a virtual battlespace. Key to creating a realistic and robust virtual environment is 
the Virtual Reality Modeling Language (VRML). VRML is a non-proprietary, 
international standard for describing virtual objects and worlds over networks. VRML is 
capable of representing three-dimensional (3D) animated objects and multimedia objects 
with hyperlinks to other media such as text, sounds, movies, and images. 

The end result of combining the powers of both XML and VRML is an intricate 
three-dimensional (3D) world populated with aircraft, terrain, and target models. The 
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virtual world permits the viewer to navigate through an ATO in both space and time and 
to observe interactions between aircraft, terrain, and targets. 



B. OBJECTIVES 

The objective of this thesis is to demonstrate the viability of using XML and 
VRML to transform and render the actions specified by an Air Tasking Order (ATO) and 
unit flight plans within a virtual battlespace. To develop a 3D virtual air plan from an 
ATO, the following critical structures must be developed: 

■ XML-encoded operational documents that describe an air plan and an ATO. 

■ An interface that will transform relevant ATO data from XML into appropriate 
VRML objects. 

■ Virtual battlespace environment design in VRML 

■ VRML PROTO libraries that are referenced by the code auto-generated from 
XML Master Operational Document (MOD) 

C. THESIS ORGANIZATION 

Chapter II reviews background information on the Extensible Markup Language 
(XML), U.S. Message Text Format (USMTF), government sponsored XML message 
initiatives, the Virtual Reality Modeling Language (VRML), and the air tasking process. 
Chapter III provides a description of the XML/VRML opportunity and a synopsis of 
implementation strategy and its relevant technical components. Chapter IV introduces a 
tactical scenario upon which the virtual air plan is based. Chapter V presents the XML 
data structures that are employed to create a rich virtual air plan. Chapter VI uncovers 
the steps required to transform an ATO into a virtual air plan. Chapter VII identifies the 
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fundamental VRML elements that make up the content of a virtual battlespace. Chapter 
Vni presents the results of the virtual air plan demonstration and describes limitations of 
the model and the transformation and rendering processes. Chapter IX summarizes the 
conclusions and recommendations for future work of this thesis. 
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II. BACKGROUND AND RELATED WORK 



A. INTRODUCTION 

This chapter reviews the fundamental concepts that are the basis for understanding 
the development and generation of animated 3D air plans. Topics examined in this chapter 
include the Extensible Markup Language (XML), US Message Text Format (USMTF), and 
the Virtual Reality Modeling Language (VRML). 

B. THE EXTENSIBLE MARKUP LANGUAGE (XML) 

1. Overview 

The explosion of the World Wide Web during the 1990’s can be directly attributed 
to the creation and implementation of the Hypertext Markup Language (HTML). The 
Hypertext Markup Language is a subset of a more extensive language called the Standard 
Generalized Markup Language (SGML). HTML has enjoyed overwhelming success due to 
its simplicity. The Hypertext Markup Language’s simplicity lies in its use of markup tads 
(character elements bracketed by *<’ and *>’) that are predefined by a standardized 
Document Type Definition (DTD). Essentially, HTML elements identify how web 
browsers display information, text, and pictures. A simple example, shown in Figure 2.1, 
displays mission data that is typically part of an Air Tasking Order. 
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<html> 






. I 


3 HTML Example of ATO Data ... HQ Q || 


<head> 


File Edit View Favorii y> Links 


man 1 


<title>HTML Example of ATO Data</title> 
</head> 


Mission Number: 100 




<body> 


Number of Aircraft: 1 




<p>Mission Number: 100 </p> 
<p>Number of Aircraft: 1 </p> 
<Cp>Type of Aircraft: F16 </p> 
(p>Aircraft Call Sign: Eaglel </p> 


Type of Aircraft: F16 
Aircraft Call Sign: Eaglel 




</body> 

</html> 








[ i§] Done | H! 


jy My Computer 


i 



Figure 2.1. HTML Example 



While HTML’s standardized DTD enables simplicity, it does not readily allow for 
the insertion of metadata (data describing data) within a web page. For example, 
programmers are unable to change the name of the paragraph elements, “<p></p>”, 
associated with mission number 100 to “<mission_number></ mission_number>”. In 
essence, HTML is not extensible. This lack of extensibility leads to unstructured data 
within HTML web pages. Consequently, it is difficult to access and manipulate data 
written in HTML. 

The Hypertext Markup Language’s inability to incorporate metadata into 
information might have been solved by the implementation of the Standard Generalized 
Markup Language (SGML). SGML permits users to define their own tagsets via a 
Document Type Definition (DTD), thereby allowing users to insert metadata through the 
creation of their own element types. However, SGML’s element type advantages are 
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outweighed by its hard-to-understand and cumbersome specification, which totals over 500 
pages. (Khare, 1999, pg. 81) In an effort to combine the simplicity of HTML and the 
information exchange advantage of SGML, the World Wide Web Consortium (W3C) 
designed a new language called Extensible Markup Language (XML). The Extensible 
Markup Language is being developed as the 80/20 solution, meaning that XML will 
provide 80% of SGML’s functionality at a cost of 20% of SGML’s complexity. 

Like SGML, XML allows users to define their own tagsets (element types) and 
therefore their own metadata. In essence, data becomes self-describing. To achieve these 
results, programmers need, at a bare minimum, to develop XML documents that are well- 
formed. In order to create well-formed XML documents, common basic syntax rules for 
tags must be obeyed. 

To produce a higher-level XML document, programmers need to ensure the 
document is valid. Validity is obtained by attaching a Document Type Definition (DTD) to 
an XML Document. Simply attaching a DTD to an XML does not achieve validity; 
programmers must also abide by the strict data-relationship rules specified within the DTD 
and the same syntax rules that create a well-formed document. Interestingly, valid XML 
documents are well-formed, but well-formed documents are not necessarily valid. (Harold, 
2000, slide 93) 

Both valid and well-formed XML documents create data trees. (Harold, 2000, pg. 
435) This is essential because XML data-transformation tools, known as parsers, can 
easily transform a XML document’s data trees into entirely different data trees. Parsers 
can also combine several data trees/XML documents into a single XML document. 
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Programmers can customize such data transformations by creating a style sheet 
with Extensible Stylesheet Language (XSL), attaching the style sheet to the XML 
document, and then processing the XML document with a parser. XSL is not limited to 
data transformations; it can also be used to display data in a format friendly to users needs. 

Besides specifying information formats, programmers will have the choice to 
provide users with multi-directional data links through the use of XLink. XLink creates 
and describes a multi-directional link between an XML document and another data 
resource. Multi -directional links give users the power to specify what data they want to 
retrieve into their XML document. 

XML and its subcomponent technology, XSL, provide the fundamental 
mechanisms to quickly and easily share data over the Internet. The XML 1.0 specification 
is well-developed and is recommended by the World Wide Web Consortium (W3C). 

Many commercial companies have integrated the specification into their products. 

However, some XML components (e.g., XLink) are still not fully specified and 
implemented. Assuming software companies developing XML capable tools and browsers 
properly implement the XML specification, XML will provide a complete environment of 
interoperability for data exchange. 

2. XML Technological Components 

a. XML Elements and Attributes 

Documents created using XML have two fundamental nodes - elements and 
attributes. Elements are the holders of data. Element names are typically named to 
indicate metadata, i.e., information about the data. A simple example is an element holding 
the mission number. 
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<mission_munber> 100 </mission_number> 



As shown in the example, the data is the number “100” and the metadata 
contained in the brackets is “mission_number.” Elements are not relegated to holding 
only data: they can be specified to hold other elements. The elements defined inside other 
elements are called children and their predecessor is called the parent. The parent-child 
relationship in an XML document is how a data tree is formed. Below is an example of a 
DTD that depicts a data tree and two simple parent-child relationships, SQUADRON and 
TAKEOFF_POSmON. 



< ! — Document Type Definitions (DTD) for Squadron --> 



<! ELEMENT SQUADRON ( SQUADRON_NAME, PLANE*) > 

<! ELEMENT S QUADRON_NAME (#PCDATA)> 

< ! ELEMENT PLANE (TAIL_NUMBER, PLANE_TYPE, CALLSIGN, TAKEOFF_POSITION) > 
<! ELEMENT TAIL_NUMBER (#PCDATA)> 

<i ELEMENT PLANE_TYPE (#PCDATA)> 

<! ELEMENT CALLSIGN (#PCDATA)> 

<! ELEMENT TAKEOFF_POSITION (LATITUDE, LONGITUDE) > 

<! ELEMENT LATITUDE (#PCDATA)> 

<! ELEMENT LONGITUDE (#PCDATA)> 




Figure 2.2. DTD Data Tree and Simple Parent-Child Relationships 
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Attributes are used to further describe elements and are typically used in two 
circumstances. First, they can be used for information non-relevant to data consumers. A 
simple example is using the “ID” attribute for element, which provides the element with a 
unique name. Another example would be attaching an attribute to an element that contains 
an email address. Assuming data consumers do not care about the type of email service, an 
attribute might be used to contain the type of email server associated with the email 
address, thus providing better support by an associated infrastructure. This is shown in 
Figure 2.3. 



DTD Representation 

<? ELEMENT EMAIL_ADDRESS (#PCDATA)> 

<! ATTLIST EMAIL_ADDRESS ernail_serwer_type| CDATA #IMPLIED> 

XML Data Representation 

<EMAIL_ADDRESS email_seroer_type= ' POP3 ' >johndoe@nauy .nps .nil</EMAIL_ADDRESS> 

Figure 2.3. Example of an Attribute 

The second way to use attributes is to substitute them in place of further 
child elements for information deemed integral to the element. Attributes are good 
alternatives for child elements because their contents can be defined in greater detail than 
an element’s contents. DTD designers typically want to substitute attributes for child 
elements when the child elements are “leaves” of a data tree. Data leaves are those 
elements that have no children. The chief reason why attributes are only used at the leaf 
level is that they cannot hold a structure well. (Harold, 2000, pg. 101) Attributes 
essentially truncate branches of an XML data tree and provide tight groupings of 
information in lieu of creating additional child elements. 



10 



Referring back to the Squadron DTD example above, the design might have 
placed all of the “PLANE” data in a series of attributes. As shown in Figure 2.4, all of the 
“PLANE” information specified in the attributes is at the same data-structure level. As a 
result, the “TAKEOFF_POSITION” element structure cannot be supported within the 
attribute. Additionally, the use of generic names for the latitude and longitude positional 
data is unsupportable because without specifically identifying new tags such as 
LATITUDE_OF_TAKEOFF and LONGITUDE_OF _TAKEOFF, it is not possible to tell 
what type of latitude and longitude data is being relayed. The values might be a flight 
position, a takeoff position, or a landing position. Thus use of attributes can provide a 
more concise, precise, and adaptable tagset. 



<! — Example of a DTD for 


PLANE using 


attributes — > 


<!ELEMENT PLANE EMPTY> 






<! ATTLIST PLANE 






TAIL NUMBER 


CDATA 


{(REQUIRED 


PLANE TYPE 


CDATA 


((REQUIRED 


CALLSIGN 


J:data 


((REQUIRED 


LATITUDE OF TAKEOFF 


CDATA 


((REQUIRED 


LONGITUDE OF TAKEOFF 


CDATA 


»REQUIRED> 



Figure 2.4. Attributes and Data Structure 



b. Document Type Definition (DTD) 

A Document Type Definition (DTD) is a list of tags that defines specific 
elements and attributes. DTDs also describe the relationships and format between elements 
and attributes. (Harold, 2000, slide 95) DTDs ensure the validity of an XML document by 
requiring the data in the XML document to adhere to the prescribed format and structure. 
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DTDs are enablers of interoperability because they can serve as the information exchange 
standard for unrelated organizations using XML applications. 

c. Extensible Style Language (XSL) 

The Extensible Style Language (XSL) is a stylesheet language within the 
XML specification. XSL is composed of a transformation language and a formatting 
language. The XSL transform language allows XML data trees to be converted into a 
different data tree. The transformation language can also synthesize several XML data 
trees into a single data tree. 

The XSL formatting language is designed to display data contained in XML 
documents. The formatting language emphasizes the rendering of data into a manner that 
suits users’ needs. In this manner, programmers can provide formatting instructions to 
convert data for any application or system. For example, a single USMTF message might 
be automatically and appropriately formatted via different XSL stylesheets for email, a web 
page, printing, palmtop display, compressed storage, etc. 

d. XLink 

XLink is an experimental XML technology that allows programmers to 
embed hyperlinks in XML data. An Xlink creates and describes a link between an XML 
document and another data resource, typically another XML document. XLink is similar to 
HTML hypertext links but more powerful. XLink will provide unidirectional links like 
HTML hypertext links, but will also go beyond this by supporting multi-directional links. 
Multi-directional links will allow users to retrieve data into their XML document from 
sources such as databases and other XML documents. 
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C. UNITED STATES MESSAGE TEXT FORMAT (USMTF) 

1. Overview of the USMTF Program 

The United States Message Text Format (USMTF) is a well-documented 
government-proprietary messaging standard used for sharing structured information. The 
Defense Information Systems Agency (DISA) is the sponsor of the USMTF program and 
maintains the configuration management of the USMTF standard for the Department of 
Defense (DOD). The Defense Information Systems Agency (DISA) and the DOD 
designed the USMTF standard to serve the purpose of enhancing “...joint and coalition 
warfighting effectiveness through the standardization of message formats, data elements, 
and information exchange procedures.” (Chairman Joint Chiefs of Staff Instruction 
6241.01, 1996, pg. 1) 

The essence of USMTF is to create an environment of information exchange, which 
allows joint forces and systems to achieve interoperability. To achieve this vision, DOD 
has established objectives for the USMTF program. They are shown in Figure 2.5. 
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1. "Produce standardized, single-syntax character-oriented 
message formats for all DOD information requirements. These 
formats facilitate the transfer of information, while 
maintaining system independence . " 

2. "Reduce the time and effort required to draft, transmit, 
analyze, interpret, and process messages." 

3. "Improve information exchange through vocabulary and syntax 
control and standardization of data elements." 

4. "Standardize information exchange procedures." 

5. "Provide uniform reporting procedures to be used in the daily 
exchange of information." 

6. "Facilitate exchange of information between the United States, 
allied commands, and other friendly nations. Reduce or 
eliminate dual reporting by US units when they operate with 
allied commands and other friendly nations." 

7. "Provide human readability where required." 



Figure 2.5. USMTF Objectives 

(Chairman Joint Chiefs of Staff Instruction 6241.02, 1996, D2. 2-3.) 



2. The Extensible Markup Language - Message Text Format 
(XML-MTF) Initiative 

The U.S. Message Text Format (USMTF) has been highly successful over the past 
three decades because it has enjoyed full buy-in from all DOD Services, Agencies, 
Commander-In-Chiefs (CINC), and allies. With this strong backing, USMTF is able to 
support the full spectrum of military operations. Despite USMTF’s long standing as the 
information exchange workhorse for DOD, USMTF is nearing the end of its useful life due 
to several limitations. 
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First, USMTF was originally developed in the 1970’s; consequently, the DOD is 
burdened by a 30-year-old acquisition strategy when maintaining USMTF. This forces the 
government to own and maintain the USMTF standard (Military Standard 6040). As a 
result, no Commercial-Off-The-Shelf (COTS) products are available to easily upgrade 
USMTF. In addition, when upgrades to the USMTF are necessary, the DOD must contract 
the work out at a higher-than-normal rate because the civilian workforce is subjected to a 
learning curve due to the workforce’s general unfamiliarity with the governmental 
standards of USMTF. (Hall, 1999, slide 6) 

The presentation style of USMTF is also a limiting factor. In the 1970’s, the DOD 
was reliant on the use of the Teletype; therefore, the presentation format for USMTF is 
restricted only to Teletype display characters, capital letters and numbers. (Hall, 1999, slide 
6) Compared to today’s web-based display of text and multimedia, USMT F’ s presentation 
format is archaic and neither reader friendly nor reader specified. 

Lastly and most importantly, the USMTF is only able to send the message itself. 
Under current USMTF methods and technologies, no metadata can be transmitted within 
the message. The utilization of metadata (information that describes data) is powerful 
because it provides the consumers of information with the ability to personally organize, 
search, filter, and render data. 

Fortunately, private industry would like to solve the problem of computer-to- 
computer information exchange over the World Wide Web and are developing XML as the 
answer. As the caretaker of USMTF, the Defense Information Systems Agency (DISA) is 
actively looking to an XML encoding as the replacement for USMTF in an effort called the 
Extensible Markup Language - Message Text Format (XML-MTF). An appropriately 
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designed XML tagset can fulfill the fundamental USMTF requirements for platform 
independent exchange of information and much more. 

The chief advantage of XML is that users can structure their data uniquely, gain 
reliable interoperability, and include metadata through the use of DTDs. This allows 
producers and consumers of information to more easily exchange data between 
applications. This capability is an important factor for DOD because many systems suffer 
from interoperability issues. With the use of XML, complex systems will no longer need 
to develop costly data translators or sub-systems to utilize and exchange information. 
Instead, low-cost, low-complexity XSL stylesheets can be used to parse and transform data 
to whatever formats are necessary. 

Since XML is a commercial standard, USMTF will no longer be tied to a 
proprietary government standard. The Department of Defense will have the ability to buy 
COTS XML tools and products that can be used to update and maintain USMTF systems. 
Additionally, there will be a knowledgeable contract civilian workforce available to 
quickly develop system updates. 

To provide DOD with the proper XML-MTF effort, the Extensible Markup 
Language - Message Text Format (XML-MTF) Development Team was formed in May 
1999. The team was charged with developing an XML-MTF specification and software 
tools that transform messages between the USMTF and the XML-MTF standards. 
(Hopkins, Brian, 2000, pg. 1). 
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At the heart of the XML-MTF Development Team’s efforts is the XML-MTF 
Mapping document. The purpose of the document is to define the rules for XML-MTF 
message documents and their relationship to USMTF messages. To aid this development, 
the XML-MTF Development Team established the following “Design Principles:” 



1* "XML-MTF shall be easy to read, use, and understand. Descriptive 
names and logical structures that resemble as much as possible the 
structure of MTF standards shall be favored over terse abbreviations 
and clever shortcuts. 

2. XML-MTF shall be designed to ensure widespread military adoption. 

In keeping with this principle, XML-MTF shall be designed to 
accommodate current MTF standards . 

3. XML-MTF documents should be easy to construct from basic rules 
mapping it to MTF formats. Transformation of XML-MTF to formats such 
as USMTF, AdatP-3, and OTH-T Gold should be as simple as possible. 

4. XML-MTF schemas should be easy to construct; drawing from the 
logical structure of MTF message standard databases, such as those 
defined for USMTF and ADatP-3. 

5. Operations on XML-MTF documents, such as a query, should be 
resilient to schema changes. 

6. XML-MTF shall use XML elements for message data, and XML attributes 
for specifying value-added annotations (e.g., classification, 
pedigree) . 

7. XML-MTF shall as much as possible draw on industry adopted standards 
and technologies to save time and money." 



Figure 2.6. XML-MTF Development Team Design Principles 
(XML Development Team, 2000, pg. 1) 

While XML offers a tremendous opportunity for DOD information exchange, 
XML-MTF is not without challenges. Like USMTF, DOD will have to establish a set of 
XML information exchange protocols. This is not an easy task because DOD encompasses 
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order to avoid creating a new set of mutually incompatible “stovepipes” and new problems 
of interoperability, DOD service branches must work together when developing XML data 
formats. Otherwise, the power of X3VEL will be severely diminished by the stampede of 
organizations creating incompatible information formats. 

D. THE VIRTUAL REALITY MODELING LANGUAGE (VRML) 

The Virtual Reality Modeling Language (VRML) is used to develop content for 
three-dimensional (3D) virtual words. One key feature of VRML is the fact that it is an 
ISO standard designed to be used over the World Wide Web in a browser environment. 

The various examples explored in this thesis employ the approved VRML97 version of the 
standard. 

The fundamental design structure in VRML worlds is a scene graph. A 3D scene 
graph is composed in VRML by grouping and encoding content into nodes. These nodes 
are used to display objects such as primitive shapes (such as Box and Sphere), elevation 
grids and complex indexed face sets. The nodes also specify groupings of sub-nodes and 
can indicate interaction and movement of events throughout the scene graph. The basic 
steps to design a scene graph are to build a world with visual nodes and then describe the 
interaction through behavior nodes. VRML provides the standardized interchange 
language to create these virtual worlds so that they can be viewed with any VRML-capable 
browser available in open source and as web browser plug-ins. 
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1 . 



Basic Nodes 



VRML has a variety of nodes that can be employed to develop a rich scene graph. 
The following is a synopsis of key nodes necessary to understand the design of the example 
battlespace virtual world presented in this thesis. 

a. Visual Nodes 

The visual aspect of a scene graph is expressed through the Shape node. The 
Shape node places primitive shapes such as cubes, spheres, and cones into a scene graph by 
defining a specific shape in the geometry field of the node. These nodes can be grouped, 
sized, scaled, colored, and textured to build entities of the virtual world. 

The Shape node is also used when trying to build more complex objects 
such as an F-15 aircraft in Figure 2.7. These complex objects can be built using indexed 
face sets. An IndexedFaceSet Node is an array of polygons used to map out an object in 
the virtual world. In general, the object is built with the help of a CAD (computer aided 
design) program or similar authoring tool The CAD software then converts and exports 
the object to a VRML compatible IndexedFaceSet Node. The F-15 of Figure 2.7 was built 
using a CAD program called RcCAD (www.rccad.com) and translated into VRML. The 
IndexedFaceSet provides a mechanism for creating complicated, realistic shapes in VRML. 
Once calculated, the object is placed as a value in the geometry field of the shape node and 
can be manipulated like any primitive shape. Shape Nodes are used to build primitive 
geometries, which can then be integrated into more sophisticated scene graphs. 
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Figure 2.7. F-15 Modeled with RcCAD 
After (Pearson, 1999) 



The Shape node also contains an Appearance node that presents the author 
with intricate control over the color of an object. The Appearance node is used in 
conjunction with the Material and Texture nodes to apply colors and texture images to an 
object. A terrain map or image could be placed over the elevation data in a virtual world to 
present a realistic setting. (Brutzman, 1998) 
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b. __ Grouping Nodes 

Grouping nodes cluster sets of nodes for the purpose of creating entities to 
be manipulated in a scene graph. The most basic of these nodes is the Group node. The 
Group node simply specifies child nodes that are to be collected together. Slightly more 
complex, the Transform node is a cornerstone node in VRML. Like the Group node, the 
transform node clusters child nodes into an entity. The Transform node is also capable of 
moving the grouped nodes within a local coordinate system. The transform node can 
specify translational and rotational changes of position to children of the node. This is a 
fundamental ability of a scene graph. The transform node can be combined with 
interpolator nodes to create animation in the virtual world. (Brutzman, 1998) 

c. Viewing Nodes 

The Viewpoint node is designed to make navigation of a virtual world easier 
for the viewer. The Viewpoint node allows a scene graph to include predefined camera 
angles for suggested viewing. These predefined views of the world are easy to access via 
the interface bar of the VRML browser and offer practical navigation. Such features are 
especially convenient and necessary in large worlds. The related Navigationlnfo node 
permits a virtual world to control how a viewer moves about the scene. A viewer may be 
forced or guided to walk (rather than fly) through a scene. (Brutzman, 1998) 

d. Interpolators and Route Nodes 

Once the geometry and rendering for virtual objects are developed and 
placed in a scene graph, it is often desirable to animate these objects. To perform such 
animation, VRML uses interpolators and routes. Interpolators are used to calculate interim 
states between key values so that the animation transitions smoothly from the start state to 
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the end state. The most common interpolators are the position and orientation 
interpolators. These interpolators are used to create translational and rotational animation 
of objects in the scene graph. 

In order for the movement to take place, such calculations must be passed as 
events into the transformation node of the object. This transfer is done via routes, which 
pass events. For example a ROUTE can take the calculated changes from an interpolator 
and redirects the data into the transform node. The modified transform node implements 
the behavior changes in the scene graph. (Ames, 1997) The prerequisite node that drives 
the animation process is the Time Sensor node. The Time Sensor provides the clock that 
the interpolators use to systematically output positional data. 

e. Sensor Nodes 

There are several types of sensor nodes in the VRML specification, each 
used to track user interactions and generate events with the virtual world. One fundamental 
sensor is the Touch sensor. The Touch Sensor activates whenever a mouse cursor or 
pointing device is placed over (or clicks on) an object. VRML also allows the user to move 
objects with the mouse via the PlaneSensor, SphereSensor, and CylinderSensor. Sensors 
provide the primary means for a viewer to interact with a virtual world. (Brutzman, 1998) 

f. Script Node 

The Script node is used to integrate imperative programming languages such 
Java and JavaScript (formally know as EcmaScript) into the scene graph. The Script node 
adds flexibility to develop more sophisticated scene-graph behaviors not inherent in the 
VRML specification. The Script node is commonly used to perform network access or 
physics calculations such as those needed by interpolators and sensors. 
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g. PROTO And EXTERNPROTO Definitions 
The PROTO and EXTERNPROTO definitions are used to create new 
VRML nodes as combinations of other predefined VRML nodes. This becomes useful 
when developing large, specialized scene graphs. PROTOs can be used to construct 
complex objects and behaviors that are referenced multiple times or referenced by many 




#VHML V2.0 Utf 8 
Group { 

children [ 

Viewpoint { 

description "initial view" 
position 6-10 
orientation 0 1 0 1.57 

} 

Shape { 

geometry-Sphere { radius 1 > 
appearance Appearance { 
texture imageTexture { 

url "earth-topo.png"}} } 

Transform { 

translation 0 -2 1.25 
rotation 0 10 1.57 

children [ 

Shape { 

geometry Text { 
string [ " Hello" "world!" 

] } appearance Appearance { 

material Material { 

diffuseColor 0.1 0.5 1 

})}])]> 



Figure 2.8. “Hello World” Source Code and Rendered World. 
From (Brutzman, 1998) 



worlds. PROTOs are a key mechanism for efficiently creating large and intricate virtual 
worlds. In order to achieve efficient code re-use, the EXTERNPROTO construct is 



provided to group PROTOs into libraries for network accessible storage and convenient 
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reference. Figure 2.8 implements several of these nodes to create a virtual earth. 

(Brutzman, 1998) 

2. GeoVRML 

The VRML specification is a powerful tool for representing 3D worlds. However, 
the specification does not directly represent or utilize geographic concepts, such as 
latitude/longitude coordinates or the corresponding navigational movement associated with 
these coordinate systems. GeoVRML 1.0 (www.geovrml.org) is a suite of nodes and 
software tools developed to simplify implementing geographic constructs in VRML97. 

The key components of GeoVRML are the PROTOs designed for referencing and 
interpolation of virtual worlds through geographic mechanisms. The GeoVRML PROTOs 
use underlying Java code and Script nodes to perform the physically-based calculations and 
perform geographic modeling. The GeoVRML suite is a Recommended Practice of the 
Web 3D Consortium. (Iverson, 1999) 

The GeoVRML nodes carry out similar functions as the corresponding nodes found 
in VRML97. Figure 2.9 shows example GeoVRML code fragment used to rebuild the 
georeferenced virtual scene displayed in Figure 2.10. 

Although the example code is missing a large number of VRML declarations 
needed to enact geo-referencing, the major nodes required to render the scene are present. 
The virtual Earth appears to be similar to the "Hello World" Earth of Figure 2.8 but is, in 
fact, more sophisticated. The two virtual worlds provide comparable visual depictions of 
the Earth, but that original "Hello World" Earth is simply a sphere wrapped in a texture 
map of the Earth. The Earth built in Figure 2.9 is composed of elevation grids geo- 
referenced by latitude and longitude. To demonstrate the power of GeoVRML, a large 
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inverted cone is place above Monterey, California by simply referencing its geographical 
coordinates. The expressive power of the geo-referenced world is further supported by its 
utility to easily specify geographical coordinate systems. 



GeoViewpoint { 

geoOrigin IS geoOrigin 
geoSystem [ "UTM" , "Zll"] 
position "3905500 578200 10000000" 
orientation 100 -1.57 

description "Welcome to Monterey" } 
#Build Earth w/ GeoElev. Grid & Lat/long 
Shape { 

appearance Appearance { 
material Material { 
diffuseColor 0.8 1.0 0.3 } 
texture DEF TEX ImageTexture 

{ url "earth.gif" }} 
geometry GeoElevationGrid { 

geoOrigin IS geoOrigin 
geoSystem [ "GDC" ] 
geoGridOrigin "-90 -180 0" 
xDimension 21 
zDimension 21 
xSpacing ”18" 
zSpacing "9" 

height [0 0 0 0... (441 total) ]}} 

GeoLocation { 

geoSystem [ "GDC" ] 

geoCoords "36.601388 -121.88166 200000" 

# Lat/Long Monterey CA 

children [ 

Transform { 

rotation 100 3.1415926 
children [ 

Shape { 

appearance Appearance { 
material Material { 

diffuseColor 100}} 
geometry Cone { 

bottomRadius 100000 



} 1 } 1 



height 500000 } 
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Figure 2.9. X3D Source Code for 
GeoVRMLWorld.wri 



Figure 2.10. Rendered 
GeoVRMLWorld.wri 



a, GeoOrigin 

Coordinate reference systems currently supported by the Geo VRML suite 
assumes that the virtual world begins at the center of the earth. In order to gain optimal 
precision of the model, Geo VRML provides the GeoOrigin node to specify the local 
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coordinate system. Only one GeoOrigin node is used within a scene, directing a browser 
where to look inside the VRML world and to interpret the geological data. (Reddy, 2000) 

b. GeoLocation 

The ability to place objects in specific locations of a scene graph is of 
fundamental importance. The GeoLocation node presents the capability to place objects in 
a virtual world using a geological reference frame. This node performs in a similar manner 
to the Transform node of VRML97. (Reddy, 2000) 

c. GeoPositionlnterpolator 

The original Transform node required the Positionlnterpolator node to 
create smooth movement for animation. The GeoLocation node also has an associated 
interpolator. The GeoPositionlnterpolator node performs the function of calculating key 
values and intermediate positions in geological coordinates. A time sensor is used to drive 
the process that passes the coordinates to the GeoLocation node effecting movement of an 
object about a geo-referenced world. (Reddy, 2000) 

d. GeoViewpoint 

The GeoViewpoint node behaves like a standard viewpoint node. The 
GeoViewpoint node relocates the viewer’s orientation and position to an absolute posture in 
the georeferenced coordinate frame. The GeoViewpoint node supplies a practical means 
for maneuvering about complex Geo VRML worlds. 

E. EXTENSIBLE 3D (X3D) 

The next-generation VRML specification is known as Extensible 3D (X3D). 
Extensible 3D is more than an update to VRML97; it is a redesign of the encoding and the 
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underlying code structure. By employing XML, the new X3D standard constructs a DTD 
tagset that allows users to develop well-formed and validated scene graphs. Using XML 
provides X3D with a robust structure and extensibility. Extensible 3D has similar 
fundamental nodes and structure as the VRML97 standard and is fully backward 
compatible. 

Using an X3D software development kit and the X3D-Edit authoring tool, 
developers can produce validated scene graphs with error-free editing. The tool kit utilizes 
IBM’s Xeena XML editor that has been configured to facilitate straightforward 
development of scene graphs that conform to X3D DTD. The X3D Edit tool converts X3D 
documents to VRML97 via an XSL stylesheet and automatically launches a browser for 
convenient debugging. Figure 2.1 1 shows a screen capture of the Program. (Extensible 3D 
Task Group, 2000) 
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0 EP ExternProtoDeclare: name: Target, url: TargeftTarget_PROTO.wrl#Target 
field: type: Node, name: geoOrigln, vrml97Hlnt: field 
field: type: String, name: CallSign, vrml97Hlnt: field 
^ field type, Strings, name. qeoSvstem. vrml97Hlnl. field 
field 
• ^ field 
0 D Group 
0 n children 

1 *0 TimeSensor: DEF. Master_Clock, cyclelnterval: 15, enabled, true, loop 
i— GeoOrigin: DEF: Air_Plan_Origm, geoSystem; UTM. geoCoords: 3905f 

0 [P] Protoinstance name: Terrain 

-^fieldValue: fieldName. geoOrigln, value: USE Air_Plan_Origln 

b f pBBBIBllM 

—^fieldValue fieldName geoOrigln, value USE Air_Plan_Orlgln 
fieidVaiue: fieldName. geoSystem, value; UTM Z1 1 
— fieldValue fieldName AircraftType, value; F-1 5 { } 

— *■ fieldValue fieldName: AircraflName, value: F-1 5 
— fieldValue: fieldName: Mission, value: Death From Above 



Process XSL Successful 



Figure 2.1 1. Screen Capture of X3D-Edit Tool 



Extensible 3D provides the critical link between the XML documents and virtual 
worlds of this thesis. Although VRML97 is the basis for many of the models developed, 
X3D provides the structure and flexibility to transform XML documents to valid scene 
graphs. Figure 2.12 and Figure 2.13 show examples of X3D and VRML code that render 
identical virtual worlds. 
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#VRML V2.0 utf 8 
Group { 
children [ 

Viewpoint { 

description "initial view" 
position 6-10 

orientation 0 1 0 1 . 57 } 

Shape { 

geometry Sphere { radius 1 } 

appearance Appearance { 

texture ImageTexture { 

url " earth- topo . png" } } 

} 

Transform { 

translation 0 -2 1.25 

rotation 0 10 1.57 

children [ 

Shape { 

geometry Text { 
string [" Hello" "world!" ]} 
appearance Appearance { 
material Material { 

diffuseColor 0.1 0.5 1 }} 

} 

] 

} 

] 

} 



<X3D> 

<Scene> 

<Group > 

< Viewpoint 

descript ion= ' ini tial view' 
or ientat ion= * 0 . 0 1,0 0.0 1.57' 
posi tion= • 6 . 0 -1.0 0.0' 

/> 

<Shape> 

<Sphere radius- • 1 . 0 • /> 
<Appearance> 

dmageTexture 

url= 1 "earth- topo. png" " 

/> 

</Appearance> 

</Shape> 

cTransform 

rotat ion= ' 0 . 0 1.0 0.0 1.57' 
translations • 0 . 0 -2.0 1.25'> 

<Shape> 

<Text s trings • "Hello " "world! "'/> 
<Appearance> 

<Material 

di f f useColors ' 0 . 1 0.5 1.0' 

/> 

< /Appearance> 

</Shape> 

</Transf orm> 

</Group> 

</Scene> 

</X3D> 



Figure 2.12. X3D Source Code for 
"Hello World" 



Figure 2. 13. VRML Source Code 
for "Hello World" 
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F. 



AIR OPERATIONS PLANNING 



1. The Joint Air Tasking Cycle 



NOTIONAL AIR TASKING CYCLE 
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Figure 2.14. Notional Air Tasking Cycle (Joint Publication 3-56.1, 1994, pg. IV-4) 



The joint air tasking cycle is the process used by the Joint Air Component 
Commander (JFACC) and staff to effectively employ air capabilities. The air tasking cycle 
is designed to be repetitive in nature, in order to accommodate changes in strategy and 
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changes on the tactical battlefield. As indicated in Figure 2.14, the air tasking cycle is 
composed of six interrelated phases. Typically the air tasking cycle lasts 72 hours: 48 
hours of plan development and asset allocation, then 24 hours of execution. 

The first phase of the air tasking cycle is Joint Force Commander (JFC)/Component 
Coordination. This is a meeting between the JFC and component commanders. During 
this meeting, the JFC provides strategic vision and broad guidance to the component 
commanders. Additionally, the component commanders have the opportunity to provide 
recommendations, assert support requirements, and state their ability to support other 
components. Specific to the air tasking cycle, the JFC (aided by the JFACC and his staff) 
decides upon the apportionment of joint air assets to ensure the air effort is consistent with 
his campaign objectives and phases. “Air apportionment is the determination and 
assignment of the total expected effort by percentage and/or priority that should be devoted 
to the various air operations and /or geographic areas for a given time period.” (Joint 
Publication 3-56.1, 1994, pg. IV-7) The JFC’s objectives and air apportionment are then 
passed along to the Target Development phase of the air tasking cycle. 

The first task of the Target Development phase is the creation of a target 
nomination list that supports the JFC’s targeting objectives and priorities. The Joint Air 
Operations Center (JAOC) then reviews the target nomination list, selects worthy targets, 
and prioritizes selected targets. The final target list, the Joint Integrated Prioritized Target 
List (JIPTL), is then distributed as the end product of the Target Development phase. 

The third phase, Weaponeering/Allocation, quantifies the JIPTL into expected 
attack results. This assessment is based on target worksheets, which are essentially 
detailed attack profiles for each target. Target worksheets include target attack objectives. 
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target descriptions, threats, aim points, number and type of aircraft, number and type of 
weapon to employ, probability of target destruction, etc. Once all target assessments and 
worksheets are completed, the final prioritized target list is merged into the Master Air 
Attack Plan (MAAP). 

The MAAP is the key element of joint air operations. In addition to including a 
target list, the MAAP contains the JFC and JFACC objective and guidance; component air 
support plans; component support requests; availability of capabilities/forces; aircraft 
allocation, and target update requests (Joint Pub. 3-56.1, 1994, pg. IV-8). The MAAP is 
also the foundation for the creation of Air Tasking Orders. The data within the MAAP 
combined with the JFC’s air apportionment decision helps the JFACC/ JFC staffs to 
allocate the appropriate type and number of sorties for each operation or task. 

Once the JFC approves the MAAP, the Joint Air Tasking Order (ATO) 
Development phase of the air tasking cycle begins. The Combat Plans section derives the 
details of the ATO, the Airspace Control Order (ACO), and Special Instructions (SPINS). 
The Combat Plans section must complete the ATO, ACO, and SPINS documents with the 
appropriate level of direction, in order for specified warfighting units to plan the fine 
details of their air missions. 

Typically, the ATO, ACO, and SPINS are created within the Contingency Theater 
Automated Planning System (CTAPS) or the Theater Battle Management Core System 
(TBMCS) and are distributed electronically in an USMTF format. Units tasked by the 
ATO input the ATO, ACO, SPINS, and other information into either the Air Force Mission 
Support System (AFMSS) or the Tactical Aircraft Mission Planning System (TAMPS). 
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Unit level mission planners with the aid of AFMSS or TAMPS create of each their 
aircraft’s air mission(s). 

The Force Execution phases of the air tasking cycle starts when an ATO time 
period begins and sorties are flown. During an extended around-the-clock air operation, 
the force-execution phase occurs 24 hours a day; however, only a single ATO is executed 
at any one time. Throughout the force execution phase, the staffs of the JFACC and JFC 
direct or redirect the execution of the ongoing air operation and make any 
target-deconfliction decisions. If any decisions affect an ATO in the force-execution 
phase, the JAOC is responsible for implementing the changes to the ATO. 

Changes in an ATO normally result from assessments completed in the Combat 
Assessment phase of the air tasking cycle. The combat assessment phase begins when the 
first sortie of an ATO launches and ends long after an ATO is executed. Combat 
assessment is done at all levels, from in-flight battle-damage assessment (BDA) reports to 
BDA evaluations of satellite imagery. BDA decisions about targets can directly impact 
sorties defined in an ongoing ATO and/or sorties in future ATOs. The 
combat-assessment phase allows air power to be flexible enough to respond to the changes 
on the battlefield. 

2. A ir T asking Order (ATO) 

The Air Tasking Order (ATO) is a data document that defines projected sorties, 
targets, and specific missions. While the ATO does not normally define the fine-level 
details of air mission routes, it does provide the framework for subordinate unit level 
planners to build coordinated air sorties. In general, ATOs supply targets, call signs, air 
controlling agencies, type and number of aircraft allocated to a target, etc. 
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Joint air planners create the ATO in either the Contingency Theater Automated 
Planning System (CTAPS) or the Theater Battle Management Core System (TBMCS). 

The final ATO is formatted in the USMTF standard to allow for the electronic distribution 
of the ATO to components, subordinate units, and command and control agencies. Due to 
the time length of the joint air tasking cycle (normally 72 hours) the JFACC staff work 
simultaneously on three ATOs, each of which is in a different phase approximately 24 
hours apart. 

3. Airspace Control Plan (ACP) and the Airspace Control Order (ACO) 

The Airspace Control Authority (ACA) is responsible for developing the Airspace 
Control Plan (ACP). The Airspace Control Authority prepares the ACP in coordination 
with the Area Air Defense Commander’s (A ADC) area air defense plan and with other 
joint operation plans. The ACA develops the ACP in a manner to ensure combat 
operations can be executed effectively without any undue restrictions. The bottom line is 
the ACP defines “the safe, efficient, and flexible use of airspace” (Joint Publication 3-52, 
1995, pg. v). 

The Airspace Control Order (ACO) is the implementation of the Airspace Control 
Plan (ACP). Like the ATO, the ACO is created in either the CTAPS or TBMCS. The final 
ACO is also formatted in the USMTF standard to allow for the electronic distribution 
components, subordinate units, and command and control agencies. 

G. SUMMARY 

This chapter details numerous associated concepts required for the transformation 
of an ATO message into a virtual world. The Extensible Markup Language (XML) is a 
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tool that provides data structure, data transformation, and data formatting. When combined 
with a powerful rendering application like the Virtual Reality Modeling Language, XML 
has the ability to revolutionize the U.S. Message Text Format (USMTF) standard for joint 
and coalition messages. 
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III. OPPORTUNITY STATEMENT AND IMPLEMENTATION OVERVIEW 



A. OPPORTUNITY STATEMENT 

Currently, Air Tasking Orders are transmitted to air wings and air squadrons in a 
message format call the U.S. Message Text Format (USMTF). While the USMTF 
program has been successful since the 1970’s, its useful life is coming to end do to the 
development of the Extensible Markup Language (XML). The Extensible Markup 
Language has the ability to both transform data structures and render data structures into 
any format; therefore, it is created the opportunity for message users to decide how they 
want to view messages. Taking advantage of this opportunity, this thesis demonstrates 
how to transform and render an Air Tasking Order as a graphically animated virtual 
world. 



B. PROPOSED IMPLEMENTATION 

Leveraging off the work of the XML-MTF Development Team, this thesis seeks 
to render an air planning messages in a 3D virtual world via use of Virtual Reality 
Modeling Language (VRML). The foundation of a virtual air plan is an XML ATO, 
which is transformed by a series of stylesheets. By combining detailed flight mission 
data for each tasked aircraft with threat data (e.g., location of enemy Surface-to-Air- 
Missile (SAM) sites) and terrain data, a realistic virtual battlefield can then be created 
using VRML. 
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c. 



PROPOSED USES OF A VIRTUAL WORLD AIR TASKING ORDER 



Representing an ATO inside a virtual world can provide operators with several 
advantages. Inside a virtual world, flight crews have the opportunity to view their sortie 
in the context of an entire ATO as well as the entire battlefield. This provides flight 
crews with real representations of their missions in the context of the “big picture.” 
Additionally, flight crews can visualize difficult aspects of their missions (such as 
geographical limitations) within the virtual world. Finally, flight crews and unit mission 
planners might intuitively identify whether there exist any airspace conflicts between 
aircraft. 

D. UNITED STATES MESSAGE TEXT FORMAT (USMTF) 

The United States Message Text Format (USMTF) is a well documented, 
government-proprietary messaging standard used for sharing structured information. The 
essence of USMTF is to create an environment of information exchange, which allows 
joint forces and systems to achieve interoperability. The USMTF has been highly 
successful over the past three decades because it has enjoyed full buy-in from all DOD 
services, DOD agencies, national agencies, Commander-In-Chiefs (CINCs), and allies. 
With this strong backing, USMTF is able to support the full spectrum of military 
operations. 

Unfortunately, USMTF is not a robust format due to one overriding limitation — 
USMTF is only able to send the message itself. Under current USMTF methods and 
technologies, no metadata can be transmitted within the message. Without metadata, it is 
difficult to transform and format USMTF messages. 
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E. 



EXTENSIBLE MARKUP LANGUAGE (XML) 



Unlike USMTF, which can only send the text of a message, XML allows users to 
create messages that contain metadata. Metadata is data that describes information. The 
utilization of metadata is powerful because it provides the consumers of information with 
the ability to transform, organize, and render data in ways that suits their needs. 
Additionally, XML can be the enabler of interoperability. XML provides the 
mechanisms to allow producers and consumers of information to more easily exchange 
data between applications. 

F, VIRTUAL REALITY MODELING LANGUAGE (VRML) 

The Virtual Reality Modeling Language (VRML) is a non-proprietary, 
international standard for describing virtual objects and worlds over networks. VRML is 
capable of representing three-dimensional (3D) animated objects and multimedia objects 
with hyperlinks to other media such as text, sounds, movies, and images. 

G. IMPENDING REVOLUTION: DATA EXCHANGE AND 
INTEROPERABILITY 

In previous generations the Department of Defense was the driver of 
technological developments. Recently, a paradigm shift has occurred and industry is now 
leading the technological revolution of the information age. New technologies are 
appearing that present the tools to solve data interoperability problems found in complex 
organizations. The Extensible Markup Language and the Virtual Reality Modeling 
Language are two recent technological developments that have the potential to impact 
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data structure, transmission, storage, and display. Additionally, "Virtual worlds can 
provide meaningful context to the mountains of content which currently exist in isolation 
without roads, links or order." (Brutzman, 1996) 
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IV. DESIGN OF AN OPERATIONAL/TACTICAL AIR PLAN 



A. INTRODUCTION 

This chapter outlines the tactical scenario, upon which the ATO is based, and the 
scenario limitations restricting the complexity of the ATO data and virtual world. 



B. SCENARIO LIMITATIONS 

In an effort to show the benefits of an integrated XML and VRML world, a 
simple attack scenario was designed to display an air plan. This scenario is completely 
notional and unclassified, but is sophisticated enough to demonstrate meaningful 
examples of XML and VRML/X3D technologies. To limit the complexity of the world, 
the following limitations are placed on the area of operation: 

1. Aside from one airbase of the friendly force, both the enemy forces and 
the friendly forces are confined to Fort Irwin, also known as the National 
Training Center, located in southern California. This action limits both 
the size of the operations area and the quantity of Detailed Terrain 
Elevation Data (DTED) that must be imported into the VRML world. 

2. Friendly force aircraft will only perform attack missions and activities. 

Air support activities, such as air-to-air refueling, are not described or 
rendered. 

3. The ranges and signatures of enemy radars are not based upon any real 
world intelligence data. Also, the mission flight characteristics of the air 
platforms are not based on any formal performance specification or data. 

4. Aside from enemy targets defined in the ATO and the XML threat 
document, no enemy ground or air assets will be represented in the VRML 
world. 
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SCENARIO DESCRIPTION 



An enemy force has invaded and taken control of historically disputed lands in the 
Granite Mountains. The enemy force has created an integrated air defense by positioning 
two early warning radars along the high points of the Granite Mountains. As shown in 
Figure 4.1, the enemy has also placed numerous SAM sites throughout their occupied 
region. An enemy airfield, located at UTM 1 IN 3942150 528000, provides ground 
troops air support and poses a threat to friendly forces. 




After (United States Geological Survey, 1969) 
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The friendly force has control of the region stretching south from the Granite 
Mountains. Currently, the friendly force is operating AH-64A Apache helicopter 
missions out of the airstrip located at UTM 1 IN 3905000 558450. Additionally, the 
friendly force has operational wings of F-15E Strike Eagles available for bombing 
missions. These wings are located to the south at UTM 1 IN 3795700 575950, which is 
located in 29 Palms. 

D. FRIENDLY FORCES OBJECTIVES AND MISSION PROFILES 

The overall objective for the friendly forces is to achieve air superiority. To 
accomplish this task, friendly forces will fly attack sorties against the enemy’s early 
warning radars, SAM sites, arid airbase. The air plan is developed to achieve air 
superiority will be separated into three coordinated phases. 

During the first phase, Apache helicopters will attack early warning air defense 
radars. The mission profile will require extremely low-level flights, at approximately 30 
meters above the surface, to avoid radar detection, All Apache flights will originate from 
the UTM 11N 3905000 558450 airstrip. Since enemy early warning air defense radars 
will be directing their attention toward the south, Apache sorties will conduct an 
end-around maneuver and attack the radars from behind. The flight profile for each 
Apache is shown in Figure 4.2. 
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Figure 4.2. 101 st Air Cavalry AH-64 Apache Helicopter Flight Patterns, 
After (United States Geological Survey, 1969) 



As the Apaches near their targets, F-15 air sorties will be launched from the 29 
Palms airbase against enemy SAM sites blocking the air corridor leading to the enemy’s 
air base. One F-15 will be devoted to each SAM site located in the air corridor. The 
F-15s will approach and attack the SAM sites from altitudes above 30,000 feet as shown 
in Figure 4.3. 
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Once the air corridor is cleared, the next wave of F-15s will enter the air corridor 



and will fly missions to destroy the enemy’s air base. These attack sorties will be flown 
at 20,000 feet and follow a flight pattern as depicted in Figure 4.3. 
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Figure 4.3. 4 th Tactical Fighter Wing and 100 th Tactical Fighter Wing 
F-15 Flight Patterns, After (United States Geological Survey, 1969) 
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E. SUMMARY 

To carry out an air plan within the virtual world, it is important to create a 
meaningful scenario that obeys the limits of complexity applied to this thesis while 
providing a realistic demonstration of new technologies. Ft. Irwin is the chosen area of 
operation because terrain data and maps are readily available. The key to representing a 
scenario is to describe the attack sorties in the ATO, unit flight plans, and threat data in 
an XML format. Once these documents are available, a virtual air plan can be created. 
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V. DESIGN OF AN XML/VRML AIR PLAN 



A. INTRODUCTION 

This chapter describes the structures and elements that are required to transform 
an ATO into a 3D air plan visualization. The fundamental structures of XML and 
USMTF bound and prescribe the data organization of this thesis. While ATO and all its 
derivative documents obey the principles of XML and USMTF, some data structures are 
slightly modified from the current draft XML-USMTF format, in order to reduce the 
complexity of stylesheet transformations. 

To create a complex virtual air plan, a modularized design approach is applied. 
Each module represents detailed scene graph objects to be rendered in the virtual 
battlespace. This modularity allows for the auto-generation of simple scene graph code 
from XML documents. 

B. AIR PLAN DATA STRUCTURE DESIGN 

1. Information Architecture 

The overall information architecture and data structures of this thesis, including 
the Air Tasking Order (ATO) and air mission profiles for each aircraft specified in the 
ATO, are bound within the constructs of the XML data tree and the USMTF message 
format standard. As briefly described in the XML section of Chapter II, XML documents 
create data trees. A simple example of a data tree is a genealogical family tree seen in 
Figure 5.1. 
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Figure 5.1. Genealogical Familv Tree 

The XML data tree is designed to follow a containment model. (Harold, 2000, pg. 
62) Under this design, XML elements can contain attributes, data, and/or children 
elements. In general, it is bad form to develop element tags that contain both simple data 
and embedded children tags; however, attributes can be gracefully combined with 
elements, allowing tags to contain either data or children. (Harold, 2000, pg. 62) 

The USMTF standard establishes the message format framework in which an 
ATO is created. The USMTF standard for ATOs supplies Joint Force Air Component 
Commanders (JFACCs) with a standardized format to transmit air taskings. In essence, 
USMTF provides the interoperability necessary for any person or system to read an ATO 
message. 

2. Air Tasking Order (ATO) Data Structure 

To achieve USMTF compliance, the XML-MTF Development Team, aided by a 
software tool designed to translate USMTF messages formats into Document Type 
Definitions (DTDs), autogenerated a DTD tagset for ATOs. This ATO DTD is the 
foundation for the ATO used within this thesis. Unfortunately, the automatically created 
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ATO DTD is enormous. When imported into Microsoft Word, the DTD contains 78,784 
characters, which equates to approximately 6000 words and hundreds of element 
declarations. This verbose tagset is not a clear or usable result. To make data generation 
more manageable, a simplified ATO (SATO) DTD has been prepared and used in this 
thesis. The SATO DTD allows for the generation of well-formed and valid XML ATOs. 
This is an important issue. If an element is required by the DTD but does not appear 
within the XML data document, the document will fail the test of validity and cannot be 
parsed through XSL Stylesheets. Thus the SATO DTD is an illustrative (and more 
practical) alternative to the current draft ATO DTD. 

A simplified ATO is also necessary to reduce the complexity of the VRML world. 
Only those elements needed to represent air attack sorties are contained in the ATO data 
structure. Data elements that revolve around support missions such as air-to-air refueling 
or reconnaissance missions are intentionally omitted. 

Although the SATO DTD is not all encompassing, it is a straightforward subset 
that does contain the same structure and element names as the XML-MTF Air Tasking 
Order DTD. Essentially, the SATO is created by “sawing off’ branches from the more 
complex data tree of the XML-MTF ATO DTD. The remaining data branches comprise 
the simplified ATO and are the branches that are required to display air attack sorties 
within a virtual battlespace. 

While the simplified ATO DTD mirrors the elemental structure of the XML-MTF 
Air Tasking Order DTD, attributes are not carried over into the to the SATO DTD. The 
vast majority of attributes appearing within the XML-MTF ATO DTD is designed for 
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identification purposes and provides no further advantages to the parsing of the simplified 
¥ 

ATO. 

3. Transforming Data Structures 

a. Simplified ATO (SATO) 

In order to modularize the preparation of ATO-related documents, the 
simplified ATO DTD and XML data are both imported into a higher-level document. 

This higher-level document is created as a shell with only one additional element, the 
“air_tasking_order_root.” The “air_tasking_order_root” is a parent whose presence aids 
the importation of both the SATO DTD and ATO XML data. The use of a shell 
document allows for all the necessary XSL processing instructions to be predefined. This 
shell also avoids a situation of having to manually insert the XSL processing instructions 
into every SATO XML document. 

To transform a SATO into a virtual air plan, the data contained in the 
SATO must be transformed and modularized into two types of XML documents: ATO 
Header document and partial unit flight plans. The new XML documents follow the 
general structure of the simplified ATO DTD. 

b. ATO Header Data Document 

The first document created from a SATO is the ATO Header Data 
document. This XML document’s DTD is a partial copy of the SATO DTD and contains 
only the elements that describe identification and time parameters. When transforming a 
SATO in an ATO Header Data document, the root element of the ATO, 
air_tasking_order, is transformed by a stylesheet into the ATO Header Data 
document’s root element, ato_header_data. 
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c. Partial and Final Unit Air Plans 

The second type of documents that are created from the SATO is the 
partial and final air plans for each unit specified within the SATO. Initially, unit air plans 
are in a partial form because the SATO only provides tasking information for a unit’s 
aircraft. As described in Section E of Chapter II, the units are responsible for using the 
information contained in the SATO to create detailed flight missions within the Air Force 
Mission Support System (AFMSS) or Tactical Aircraft Mission Planning System 
(TAMPS). 

Aside from the detailed flight missions, the data contained within both the 
partial air attack plan and the final air attack plan maintain a similar structure to the 
simplified ATO. The exceptions to the structure are several parent nodes, such as 
tasked_country_segment, tasked_country, etc. which is not carried over 
from the SATO into the unit air attack plans. However, the children of each parent node 
containing data are transferred into the unit air attack plans. The deletion of these two 
parent nodes is performed in order to simplify the data structure. These two parent nodes 
serve no purpose within the unit air attack plan data sets. Also, the root element of the 
SATO is transformed into the root element of the unit air plan. 

A unit’s final air plan is created once the detailed flight plans for each of 
the units’ aircraft are entered into the partial air plan. The detailed flight data is 
constructed to contain two fundamental components: the waypoint location, and the time 
of day when the waypoint is reached. These two data components are separated from 
each other in different parent nodes as shown in Figure 5.2. 
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< rout e_f ield_group> 

< rou t ©_point_rou t e > 

<point_and_altitude rout e_point_ixurober= n 0"> 

<rou t e_point_utm_l_me t ©r > 

<utm grid zone designation>ll</utiQ grid zone designation 
<utm grid zone hemi sphere >N< /utm grid zone hemi sphere > 
<utm_jgrid_zone_row>3 9< /utm grid zone row> 

<utm_l 0 000 0_meter_square_row>05 < /utm_l 0000 0_meter_square_row> 
<utm_l_me ter_northing> 5 0 0 < /utm_l_meter_northing> 

<utm grid z one_column> 5 < /utm grid z one_column> 

<utm_l 000 00_meter_square_column> 5 9 < /utm_l 0000 0_me t er_S(juare_column> 
<utm_l_meter_east ing>00 0 < /utm_l_meter_easting> 

< / route_point_utm_l_met er > 

<route_point_altitude_in_met ers >17 4 < /route_point_alti tude_in_met ers > 
</point_and_altitude> • 

• 

<point_and_altitude route_point_iiuinber=''5 ,, > 

< route _point_utm_l_meter> 

<utm grid zone designation>ll</utm gxid zone designation 
<utm grid zone hemi sphere>N< /utm grid zone hemisphere > 

<utm grid zone row> 3 9 < /utm gxid zone row> 

<utmJL0 0 0 0 0_meter_square_row>0 5 < /utm_10 0 0 00_meter_square_row> 

<u tm_l_me t er_northing > 5 0 0 < /utm_l_met er _northing > 

<utm grid zone column>5< /utm grid zone column 

<utm_l 0000 0_meter_square_column> 5 9 < / u tm_l 0000 0_me t er_square_column> 
<utm_l_me ter_eas t ing> 0 0 0< /utm_l_meter_eas ting> 

< / rou t e_poin t _u tm_l _me t er > 

<rout e__point_al t itude_in_meter s > 0< / route_point_alt i tude_in_me t ers > 

< /point_and_alt itude> 

</route_point_route> 

<t ime_of __posit ion_rout e > 

< cumul at ive_ato__t ime__in_s ecands 
route_point_number= "0 n >0< /cumulative_ato_time_in_secands> 

<cumulat ive_ato_t ime_in_s ecands 



Figure 5.2. Waypoint Locations and Waypoint Arrival Times 
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An alternative structure, as shown in Figure 5.3, is to have each waypoint contain both 
location and time. 



<route_f ield_group> 

<route point altitude in hundreds of feet> 0 
</route_point_altitude_in_hundreds_of_f eet> 

< t ime_o f __po s i t i on_r ou t e > 

<cuinulative_ato_time_in_seconds> 0 </cumulative_ato_time_in_seconds> 

< / 1 ime_o f _po s i t i on_rout e > 

<route_point_route> 

<route_point_number> 0 < / route_point_number> 

<route_point_utm_l_ineter> 

<utm_grid_zone_designation>ll</utm_grid_zone_designation> 
<utm_grid_zone__hemisphere>S</utm_grid_zone_hemisphere> 
<utm_grid_zone_column> 05 < /utm_grid_zone_column> 

<utm_100000_meter_square_column> 59 </utm_100000_meter_square_column> 
<utm_l_meter_easting> 0000 < /utm_l_meter_easting> 

<utm_grid_zone_row> 39 < /utm_grid_zone_row> 

<utm_1000 00_meter_square_row> 05 </utm_100000_meter_square_row> 
<utm_l_meter_northing> 5000 </utm_l_meter_northing> 
</route_point_utm_l_meter> 

< /route_point_route> 

< / rout e_f ie 1 d_gr oup > 

Figure 5.3. Alternative Waypoint Data Structure 



The alternative waypoint data structure is more difficult to parse into VRML 
code. The VRML code for ATO representation requires the waypoint times and locations 
to be separated into different fields as shown in Figure 5.4. The chosen waypoint data 
structure in Figure 5.3 is easier to convert into VRML. 
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DEF EARLYBIRD 2 
Aircraft { 

geoOrigin USE AirPlan_Origin 
geoSystem ["UTM", "Z"] 

AircraftName " APACHE " 

AircraftType [ APACHE {Top_Description * *EARLYBIRD2 ** } ] 
CallSign " EARLYBIRD2 11 
MissionNumber n EWRADARO 2 " 

Mission "INT" 



Takeoff Position "3905500 559000 0" 
WayPoints ["3905500 559000 0" 

"3905500 559000 9.15" 
"3923500 536500 9.15" 
"3923500 536500 9.15" 
"3905500 559000 9.15" 
"3905500 559000 0" 

] 

WayPointTime [ 0 

0.00370 

0.40389 

0.57056 

0.97075 

0.97446 



Figure 5.4. VRML Waypoint Structure 



d. Threat Data Document 

The threat data document provides the last set of XML data that is 
required to display an air plan in a virtual battlespace. This document is not derived from 
the SATO; however, its data structure is related to both the SATO and finalized unit air 
attack plans. The threat data document defines each threat known in the area of operation 
by identifying the type of threat (i.e., early warning radar) and the positional data of each 
threat. To develop a more realistic data structure, future work must identify how 
intelligence threat data is best structured and expressed. 
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e. Master Operational Document (MOD) 

The final XML document used within this thesis is the Master Operational 
Document (MOD). The DTDs and XML documents for the ATO Header Data, Threat 
Data, and all final unit air attack plans are imported into the MOD. Therefore, the 
MOD’S data structure is defined by the DTDs of each imported document. 

C. VIRTUAL AIR PLAN DESIGN 

1. Overview 

Designing the virtual battlespace is a matter of determining which elements of the 
air plan offer the visual contexts necessary to construct a 3D world. Once the visual 
elements are determined, the air-plan data is translated and expressed as PROTOS in a 
scene graph structure. The key to building a complex virtual air plan from auto- 
generated code is modularity. Grouping the air plan elements into macro-sized modules 
simplifies the translation process and allows for simpler object generation. 

2. Visual Elements 

The most obvious elements to translate into the virtual air plan are ones that 
denote shapes. If an air plan tasks an F-15 fighter, then the virtual air plan must display a 
representation of that aircraft. There is no need to translate directly to individual shapes 
or intricate surfaces. The auto-generated code can reference complex structures to be 
rendered (such as an F-15 Eagle aircraft) by a single name. 

The virtual battlespace also uses less-apparent visual elements. Unit information 
crucial to the understanding of visual cues is captured from the XZML air plan. Such 
information includes aircraft call signs, mission numbers, and mission types. These 
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elements are displayed as text on a heads-up-display that is attached to each visual object 
(e.g., each aircraft). The textual information is an important assist for interpreting a 
potentially complex and confusing visual picture. 

3. Animation Elements 

The virtual air plan is made dynamic by animating objects. These animation 
elements must be derived from tasking waypoints in the XML Air Plan. The take-off 
position and waypoint elements are the essential ingredients to bring a virtual air plan to 
life. The aircraft position is interpolated between waypoints and is moved at a speed of 
advance calculated from the associated waypoint arrival times. These elements can also 
be used to supply visual indications of flight routes and target assignments. 

4. Elements of the Virtual Air Plan 

The virtual air plan is classified into three groups. The first group contains terrain 
and geographic information. The autogeneration and mapping of terrain is a complex 
process and a separate area of active work. Because of this complexity, the air plan takes 
place over a static location. Although the air plan can be moved to any part of the world, 
only the fixed location will contain accurate and defined terrain representation. 

The second group is aircraft elements. An aircraft’s shape and animation 
elements are pulled from the XML air plan and placed into a scene graph format. The 
data structure in Figure 5.5 encompasses all of the information needed to render and fly 
an aircraft within a virtual battlespace. These elements are grouped together so that 
information is compartmentalized and multiple aircraft can be rendered and referenced in 
a single world without confusion. 
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<Aircraft> 

<Aircraf t_Type> 
<Call_Sign> 

<Mi s s ion_Nmber > 
<Mission_Type> 
<Take_of f_Position> 
<Waypoints> 



Figure 5.5. Elements required to render a flying aircraft 



The last group to be classified in this thesis is the target elements. Targets are less 
complex to render and contain fewer elements than moving aircraft. The only data 
elements required to render target are target type (needed to reference a corresponding 
structural model), and a target location. 



<Target> 

<Target__Type> 
<Target_Location> 
</ Target > 



Figure 5.6. Elements required to render a Target 



5. Virtual Air Plan Composition 

The 3D air plan design is composed of three parts: the autogenerated 3D air plan, 
visual model libraries, and behavior libraries. The auto-generated 3D air plan is the data 
elements parsed from the XML air plan and restructured to conform to a scene graph 
format. Figure 5.7 illustrates the various elements of the virtual air plan. 



57 



The visual model library is comprised of all the named macro elements required 
to render visual components of the air plan. This library is populated with aircraft 
models, target models, and track symbology. The behavior library compiles the events 
and actions that take place in the virtual air plan. These actions include flying in a 
georeferenced world and presenting heads-up displays. These libraries allow the 
autogenerated 3D air plan to be composed of basic elements that reference complex 
geometric structures and animation. 




Figure 5.7. Relationships of Virtual air plan Components 
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6. Virtual Battlespace Navigation 

The virtual battlespace is composed of multiple levels of detail controlled by 
predefined viewpoints. The entry-level viewpoint high above the 3D scene appears to 
present a two-dimensional animated map of the air plan. This first level provides an 
overhead view of the theater with elements represented by track symbology. The second 
level of viewpoints supplies a more complex level of detail by simply moving closer to 
various areas of the theater and rendering actual entities (instead of symbology). 

There are multiple relative viewpoints attached around each aircraft object. The 
position of these viewpoints moves with the aircraft as it flies and gives a relative visual 
perspective of its relationships to the terrain and to other aircraft. The last set of 
predefined viewpoints present multiple side looking and oblique angles that give a depth 
perspective of the terrain and the altitude-assignment stratification of the air plan. These 
world-fixed viewpoints offer convenient navigation and enhanced understanding of the 
aircraft, target and terrain interaction. 

D. SUMMARY 

To manage the process of constructing an air plan within a virtual battlespace, it is 
imperative to define basic data structures and scene graph elements. Not only is this 
good practice, but also the structures offer convenient manipulation of data. This chapter 
described the simple structures and elements that are used in this thesis for the 
transformation of an ATO into an exemplar 3D air plan. 
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VI. IMPLEMENTATION OF AN XML ATO TO A VRML AIR PLAN 
A. INTRODUCTION 

This chapter describes precisely how to convert an XML Air Tasking Order 
(ATO) into VRML source code. In order to provide a virtual battlespace air plan, several 
data processing steps must be traversed to produce VRML code. From the starting point 
of the simplified ATO (SATO), relevant data are extracted from the SATO, modularized, 
reconstituted and combined with other XML data documents to produce VRML source 
code. Figure 6.1 provides an overview of the entire process. 
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B. XML/XSL PARSERS 



An application called an XSL parser is at the heart of all the data processing. An 
XSL parser traverses an XML data tree and executes XSL rules contained in a stylesheet. 
While many different XSL parsers exist, this thesis uses the Instant Saxon 
implementation (Kay, 2000). The choice of Instant Saxon is based on the following: 

1 . Instant Saxon is a complete implementation of the XML specification. 

2. Instant Saxon has been proven to be very robust. The developers of the 
Extensible 3D X3D Edit program, a sophisticated XML-based application, 
have successfully used Saxon. 

3. It runs on the Windows platform. Executables are also available for other 
operating systems. 

4. The program is free for commercial and non-commercial use. 

5. Instant Saxon is easy to use and install. 

6. Saxon has extensive documentation, examples, and source code available. 
Instant Saxon is invoked from an operating system command line. An example 

command line is shown in Figure 6.2 and follows the format of: 

saxon [options] source. xml style. xsl 
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■Microsoft <R> Uindous 98 

<C>Cop y right Microsoft Corp 1981-1999. 



|C:\WINDOUS>C:\saxon — o C:\atoJheader.xnl C:\ato.xml C:\ato_Jieader.xsl_ 



MS-DOS Prompt 






Ms aJ 



Figure 6.2. Example of an Instant Saxon Command Line 



The phrase “C : \ saxon” identifies the location and name of the Instant Saxon 
executable file. The phrase “-o C : \ato_header . xml” is an option that tells Instant 
Saxon to create an output file with the name of “ato_header . xml”. There are several 
more options available to programmers, but the output option is the only one used in this 
thesis. The remaining components of the command line, “c : \ato . xml” and 
“C : \ato_header .xsl” identify the location and names of the source ATO and the 
conversions-stylesheet files. 

To adequately understand the parsing of the ATO and the Master Operational 
Document (MOD), readers must be acquainted with the file structure used in these files. 
To make things as simple as possible, all the files are stored in a single folder named 
“Demo”. 
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C. XSL PARSING OF THE ATO TO IDENTIFY TASKED UNITS 

Before the ATO is divided into modularized XML documents, the stylesheet must 
identify which air units have been tasked within the ATO. Additionally, the caretaker of 
the Master Operational Document (MOD) must also identify all the units specified in the 
ATO. This step is required to create the entity calls, which import DTDs and XML data. 

To identify units tasked in an ATO, a simple stylesheet named 
“units_in_ato.xsl” is created to display all unit designator names inside a Hypertext 
Markup Language (HTML) file. In this thesis, the HTML file is named 
“units_in_ato.html” for consistency purposes. This file can be viewed in either a 
web browser or a text file editor. 

The stylesheet works by applying HTML tags at the root node. Many tags simply 
recur on children tags. The parser traces through the branches of the ATO that contain 
the “tasked_unit_designator.” The stylesheet simply applies HTML paragraph 
tags around the value of “tasked_unit_designator.” Figure 6.3 shows a condensed 
version of the stylesheet. The entire stylesheet can be found in Appendix F. 
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<xsl :tenplate match =,, /"> 
<html> 

<xsl :apply-tenplates/> 
</html> 

</xsl :tenplate> 



<xsl :tenplate inatch="tasked_country_segment"> 
<xsl :apply-templates/> 

</xsl:tenplate> 



<xsl :template match= , ’seruice_tasked_segment"> 

<xsl :apply-templates/> 

</xsl :tenplate> 

<xsl :template natch= ,, task_unit_and_location_segnent"> 
<xsl :apply-tenplates/> 

</xsl :tenplate> 

<xsl :tenplate natch =,, tasked_unit_and_location*‘> 
<xsl :apply-tenplates/> 

</xsl :template> 

<xsl:tenplate natch^'tasked^ni^designator'^ 

<P> 

<xsl :value-of select=" ."/> 

</P> 

</xsl :tenplate> 



</xsl :stylesheet> 



Figure 6.3. Condensed units_in_ato Stylesheet 



To process the ATO with the “units_in_ato.xsl” stylesheet, the following 

single command is typed into an operating system command line: 

C:\ISaxon\saxon.exe -o C:\Demo\units_in_ato.html C:\Demo 
\ATO.xml C:\Demo\units_in_ato.xsl 

Once “units_in_ato . html” is created, users can open the file and review the results 
within a text file editor or a web browser. 
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D. XSL PARSING OF THE ATO TO CREATE AN ATO HEADER DATA 
DOCUMENT 

To begin breaking the ATO into modularized pieces, the data that constitutes the 
header data is extracted from the ATO and put into a separate file. The caretakers of the 
MOD complete this task. Under the design of the demonstration, the unit mission plans 
have no need for the ATO header data. 

As represented in Figure 6.4, the “ato_header_data .xsl” stylesheet is applied 
to the ATO and creates another XML document called “ato_header_data . xml.” The 
arrow represents the stylesheet that transforms the SATO’s data into the ATO header data 
document. Aside from a change in the root element names, the new document maintains 
the same data, XML tag names, and structure as the corresponding header data in the 
ATO. The “ato_header_data . xsl” stylesheet, which can be found in Appendix J, 
simply traverses the ATO header branches of the SATO and places all the data and XML 
tags into the “ato_header_data .xml” document. 

To process the SATO with the ATO header data stylesheet, the following 
command is typed into an operating system command line: 

C:\ISaxon\saxon.exe -o C:\Demo\ato_header_data.xml C:\Demo 
\ATO.xml C: \Demo\ato_header_data.xsl 
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Air Tasking Order 

ato tasking order 

op e ratio n_ id entific ationdata 
messageidentific ation 

effective _day_time _frame 

b eginningjl ate_time_ J gro up 
end ingda te_time_gro up 
a 5 of date time group 

tasked_country_ segment 
taske d_co untry 
c o unt ry_o f_t he _wo rid 
se me e _tas ke d_s e gme nt 
seivicejasked 
tasked_service 

task_unit_and_bcation_segment 
taske d_unit_and_location 
taske d_unit_designator 
taske d_unit_loc ation_taskunit 
icao_base_name 
place _name 

geograp hie _lo c a tio njb t_lo ng^jninute s 
aircraft_mission_data_9e gment 
indivddual_aircrafl_mission_data_segme nt 

individmlaircraftmissiondata 
airc raft_ mission data 
aircraft mis sionloc ation_segment 
gro und target lo cation 



ATO Header Data 

ato_header_data or unit _ai r_a tt ac k_pl an 

op e ratio nid entific ationdata 
mes s ageid entif ic ation 
effective _day_time _frame 
b eg inning^d atet ime_gro up 
endingdatetimejgroup 



** Elements highlighted in bold have children that hidden for reasons of brevity 



Figure 6.4. Representation of the ATO Header Data Stylesheet Transformation 



E. XSL PARSING OF THE ATO TO CREATE A PARTIAL AIR PLAN 

The second type of document created from the ATO is partial air plans. A partial 
air plan is produced for each unit that the SATO tasks. As represented in Figure 6.5, the 
stylesheet parses only data that individual units need to create their attack sorties, thereby 
reducing redundancies in elements and data. Partial air plans are a necessary 
intermediate step because the SATO does not contain any detailed flight data. It is up to 
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each unit to create their own unit air plan from the Master ATO. This job can likely be 
further simplified by condensing the DTD for the Master ATO DTD to eliminate 
unnecessary redundancies. 



Air Tasking Order 



ato_taslung_order 

op e ratio n_ id ejitific ationd ata 
messageidentific ation 
effe c tive jl ay_time JEr ame 
beginningjlatetimej^up 
ending da tetimejgroup 
as_o fd atetimejgroup 
tasked_country_segme nt 
taske d_country 
Country of the world [ 
service Jasked_se gment 
service tasked 



task_unit_and_location_segment 
taske d_unit_and_location 
taske d_umt_de signator 
taske djrnit Joe ationjaskumt 
icao_base_name 

place name 



| ^ geographic lo cati on _lat_ton^ininutes f 

Aircraft mission data segment 
indMdual_aircraftjnissionjkta_9e gment 

1 individual aircraft mission data 

aircraft mission data 



missian_nnmber 
pnmaiy_mission_type 

airc raftmissionbe ationsegment 
) ground target jpeation ^ 



Partial Unit Air Plan 




mut_air_attack_plan 

country_of_the_vrorld 
*tasked_se rvice 
^tasked_unit_and_bcation 
tasked_unit_designatar 
tasked_unit_bcation_taskurut 
icao_base_name 
place_name 

^ geographic loc ation_Iat_Iong_ruriuies 

aircraft _rnission_data_se gment 

liridmlaircraftimssiondata 
r groimd_ targe tloc ation 



** Elements highlighted in bold have children that hidden for reasons of brevity 



Figure 6.5. Representation of the ATO Header Data Stylesheet Transformation 
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Unit stylesheets are designed to create modularized partial air plans from the 
SATO for each unit. Each unit must have its own unique stylesheet in order to capture 
only the data pertaining to their unit’s aircraft. This is accomplished through the use of 
three XSL “choose” statements. As seen in the condensed stylesheet in Figure 6.6, a unit 
can be uniquely identified within the ATO by the values contained in the elements 
country_of_the_world, tasked_service, and tasked_unit_designator. 



<xsl : template match =, 'air_tasking_order_root*'> 
<xsl :apply-templates/> 

</xsl :template> 

<xsl: template match="air_tasking_order M > 
<unit_air_attack_plan> 

<xsl :apply-templates/> 
</unit_air_attack_plan> 

</xsl :template> 



<xsl :template match="tasked_country_segment"> 

<xsl :choose> 

<xsl : when test= ,, tasked_country/country_of_the_uorld= ’ USA ‘ "> 
<xsl :apply-templates/> 

</xsl :when> 

</xsl :choose> 

</xsl:template> 



<xsl rtemplate match= ,, seruice_tasked_segment' , > 

<xsl :choose> 

<xsl :when test="seruice_tasked/tasked_seruice= * USAF * *'> 
<xsl : apply- temp late s/> 

</xsl:when> 

</xsl :choose> 

</xsl :template> 



<xsl :template match= ,, task_unit_and_location_segment ,, > 

<xsl:choose> 

<xsl :when test=' , tasked_unit_and_location/tasked_unit_designator= * JUTFW' ”> 
<xsl: apply- templates/> 

</xsl:when> 

</xsl :choose> 

</xsl:template> 



</xsl:stylesheet> 

Figure 6.6. Condensed Partial Air Plan Stylesheet 
Showing the Identification of the U.S. Air Force 4 th Tactical Fighter Wing 
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To process the ATO with a unit’s stylesheet, the following command is typed into 
an operating system command line: 

C:\ISaxon\saxon.exe -o C:\Demo\4TFW_partial_air_plan.xml C:\Demo 
\ATO .xml C : \Demo\4TFW_air_attack_plan.xsl 



F. CREATION OF FINAL UNIT AIR ATTACK PLANS 

To convert the partial air plan into a final air plan, a low-technology approach 
is followed. Each aircraft’s flight plan, to include waypoints, altitudes, and times, is 
manually typed into a unit’s partial air plan as part of the mission_routing_data 
branch. Once every aircraft’s flight mission is entered into the unit’s partial air plan, 
the final unit air plan is completed. This process is shown in figure 6.7. 



Partial Unit Air Plan 



mut_arr_attack_plan 

country_of_the_WDrld 

tasked_service 

tasked_umt_and_bcation 

tasked_uiut_dj“signator 

tasked-Unit-bcatLon_taskunit 

icao_base_name 

place-name 

geographicloc ationlatlo ng_minul es 

a it c raft _mi ssion_data_se gme nt 

indiid ualairc raf tnds % iond ata 
gioundtaigetloc ation 



Final Unit Air Plan 



Detailed Aircraft Mission Data 



mission-routing -data 
d ay time and mo n th- of _ si art 
d a Y-time and mo n th_ of_ si op 
takeoff_p osidon 
route -fieldjgroup 
route_p ouitroute 




/(moTair-attack-plari 
co unt ry-Of-the-World 

tasked-Service 

tasked-Unit-and_location 

taske d-Unit-de sdgnator 
taske d-Unit-loc atbu-taskuni t 
icaO-base_name 
place-name 

geographicloc alio nlallo ngjminul es 
aircraft-mission_data-Segme nt 

Didkridualaircraft-missiin-dala 
ground- tai^etloc ation 
mission-routing-data 
d aytimeandmo nth_ of_ start 
d aytimeand mo nth_ of slop 
takeoff-posidon 
route -field__group 
route_p ointroute 



** Elements highlighted in bold have children that are hidden for reasons of brevity 
Figure 6.7. Creation of Final Air Plans 
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G. MASTER OPERATIONAL DOCUMENT (MOD) 

The MOD is a shell document used as a kind of integration template, where all the 
modularized DTDs and XML documents are imported and combined. The importation of 
DTDs and XML documents are accomplished through the use of external-entity XSL 
declarations within the MOD. The reconstitution of the DTDs and XML documents from 
various components is illustrated in the Figure 6.8. 



tarain_data 

geo_Origin 

ato_header_data o r unit_air_att ackjlan 

operancmidaitificatiandata 
messag e _i d entifi c atio n 
effective_dayjimejrame 
b egiimmg_da te_time_group 
exiding_date_tiine _group 



umt_air_attack_plan 
countiy_of_the_wcrld 
tasked_service 
tasked_umt_and_l o cation 
tasked_umt_desi gnator 
tasked ju rut Jocab on_taskumt 
icaoJia$e_naxne 
place_name 

jeographic_locatiaB_lat_lon«_minul« 
awe raft _mi sst on_dat a_s egment 

individoalair era ft_nrissian_da ta 
groundjar get Jocation 
mis$ion_routingjiata 
day _time_and_m anth_af_start 
day _time_and_ra anth_af_st op 
takeoffjDOsitian 
routejieldjgroup 
routej oint_route 



threat_data 

threat 

threat_type 

| threat_posibon_and_elevation 

thr eatlocatianutmlm star 
threat elevation in meters 



terrain data XML 



ato_h e aier _data_X ML r 



air _pl an_ 1 C 1 AJRC AV_XM L , 



air_plan_10QTFW_XML 



air_pl an_4 TF W_XM L 



threat_data_XML 



<IDOCTYPE MOD [ 

^ELEMENT MOD (terran_data. atoJieader_data, u mt _ai r _atta ck_p 1 an *, threat_data)> 



< i ELEMENT terrain_data (geo_Ongin_utm_l_meter)> 

<i ENTITY % terram_entity SYSTEM u t«Tain_data.dtd"> 
%terrain_ entity, 



< 1 ELEMENT ato _header_dat a (op er ad on_id end ficati on jiata ? , exercise_identification? 

message_identification?, effective_day_time_frame) > 
-►<tENTrry% ato_header_data_entity SYSTEM M ato_header_data. dtd" > 

%ato_header_data_entity, 

< I ELEMENT unit_air_attack_pl an (country jofj±ie_world, tasked_sennce, tasked_umt_andJo cation, 
aircraft mission data segment)> 

► <IENTITY%unit_air_attack_plan_entity SYSTEM *umt_air_attack_plan.dtd , > 



LB 



°/ounit_aw_attack_plan_entity, 

<! ELEMENT threat_data (threat*) > 

' ENT IT Y % threat_dat a_enhty SYSTEM “threat_datadtd“> 

%threat_data_entity, 

<1- External General Entity Definitions for XML Data ~> 

< ! ENT FT Y texrain_data_X M L S Y STEM " texrain_data xml " > 

<' ENTITY ato_header_data_XM L SYSTEM "ato_header_data.xxnT> 

< i ENTITY airjDlan 101AIRCAV XML SYSTEM M01AIRCAV ar_plan.xmT> 
c'ENTITY air_plan_100TFW_XML SYSTEM " 100TFW_atr_planxml‘‘> 

< i ENTITY air_plan_4TFW_XML SYSTEM "4TFW_air_plaaxml'> 

< i ENTITY threat data XML SYSTEM 'threat dataxml'> 



<MOD> 

<&.terrain_clata_XML. <•- External General Entity Call for data -> 

&ato Jieader_data_XML, <!-- External General Enbty Call for data --> 

&ar_planJ0 1AJRCAV_XML, <•-- External General Entity Call for data --> 
&ar_pl an_ 1 0 OT FW_X M L, External General Entity Call for data «> 

&ar_plan_4TFW_XML, <1- External General Entity Call for data ••> 
&threat_data XML, <>- External General Entity Call for data -> 
</MOD> 



Figure 6.8, Representation of Master Operational Document 
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H. XSL PARSING OF THE MOD INTO VRML 



The final step in creating a virtual-battlespace air plan is transforming the MOD 
into VRML source code. Like any other XML transformation, a stylesheet is applied to 
the MOD. Although the MOD contains terrain and ATO header data, these documents 
are excluded from the air plan’s current representation within the VRML world. 
Therefore, the stylesheet concentrates on parsing out two fundamental components - 
aircrafts and threats. 

Each aircraft is comprised of three components: aircraft waypoint location, 
waypoint arrival times, and aircraft identification data. All the aircraft data has been 
structured in a manner to allow for the easiest parsing. The stylesheet travels through the 
MOD data tree and selects the values of key elements with “value-of ’ statements. An 
example is shown in Figure 6.9. The threat data is similarly transformed by the 
stylesheet. 

To process the MOD with a VRML conversion stylesheet, the following 
command is typed into the command line: 

C:\ISaxon\saxon.exe -o C:\Demo\VRML_air_plan.wri C:\Demo 
\MOD . xml C : \Demo\MOD_to_VRML . xsl 

Once the VRML source code is created, users can navigate through the virtual- 
battlespace air plan with a VRML browser. 
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< x si :tem pi ate m atch= " r oute_fi el d jgr oup "> 

<x si: apply-templates£> 

</xsl: tempi ate> 

<x si: tempi ate m atch= " route_p oint_r oute ,l > 

< x si : tex t dis abl e- output- e sc apmg= "ye s" > 

Waypoints[</xsl:text><xsl:apply-templates/><xsl:text di sable- output e sc apmg= "yes">]</xsl:text> 
</xsl:template> 

< x si : tempi ate m atch= " pomt_and_al titude "> 

<x si : t ex t> <& quot,< /x si : tex t>< x si : apply- tempi at es/> < x si :tex t>& quot;< /x si: tex t> < x si: tex t> < /x si : text> 
</x si . tempi ate> 

<x sl:template match= "route_pomt_utm_l _meter"> 

< x si : apply-templ ates/> 

</x si: tern plat e> 

< x si :tem pi at e m atch= " utm gri d_z ctne_row" > 

< x si: value- cf select= 

</x si: tempi ate> 

< x si :tem pi at e m atch= " utm _1 0 0 000 _m eter_square_r ow"> 

< x si: value- cf select="."/> 

</xsl:template> 



< x si :tem pi ate m atch= " utm _1 _m eter_ea sting" > 
<xsl:value-of select=". "/><xsl:text> </xsl:text> 

</x si: tempi ate> 

<x sl:template match= "route_pomt_altitude_in_m eters"> 
<x si: value- cf select=VV> 

</x si: tern plat e> 



Figure 6.9. Waypoint Parsing 



I. 



SUMMARY 



This chapter describes how ATO information is divided and distributed among 
derivative documents. These documents are combined with a threat data document to 
create a Master Operation Document. The MOD contains the data of the detailed air plan 
that is transformed into VRML source code via a stylesheet. 
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VII. IMPLEMENTATION OF THE VIRTUAL-BATTLESPACE AIR PLAN 



A. INTRODUCTION 

The virtual-battlespace air plan is implemented with the Virtual Reality Modeling 
Language. Although many other methods exist for displaying 3D worlds, such as Java 
3D, VRML offers a non-proprietary, international standard for describing virtual objects 
and worlds over networks. The virtual world is viewed in a standard web-browser 
environment with freely available add-on software such as Cosmo Player or Cortona. 
Another advantage of VRML is its ability to utilize the Geo VRML Recommended 
Practice that provides convenient geo-referencing functions. The virtual air plan is made 
of modularized code (i.e., PROTOs) that renders the virtual world. 

B. VIRTUAL AIR PLAN COMPOSITION 

1. PROTO Modularization 

The virtual air plan is autogenerated with modular VRML code known as 
PROTOs. The PROTO code is stored in separate files and is only instantiated in the 
virtual world. This allows the virtual world to call up and pass data to the PROTOs. The 
three main PROTOs referenced by the virtual air plan are the Aircraft PROTO, Target 
PROTO, and the Terrain PROTO. Each of these PROTOs calls upon other PROTOs to 
perform specific functions, such as turning on a Heads-Up Display (HUD). Figure 7.1 
illustrates several of the PROTOs developed to render the virtual air plan. 

The figure depicts the PROTO hierarchy necessary for such modularity. These 
PROTOs contain all the information required to render objects and behaviors in the 
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Figure 7.1. Relationship of PROTOs Used to Generate the 
Virtual-Battlespace Air Plan 



virtual world. Every time the virtual air plan tasks an aircraft or target, the virtual world 
calls on the appropriate PROTO to render objects and maintain contextual information. 

2. Virtual Composition 

The virtual air plan is composed of four parts. The first part is made of the 
EXTERNPROTO declaration statements. These statements permit the air plan to access 
the PROTO libraries, which contain aircraft, target, and terrain models, as well as 
GeoVRML functions. The second set of PROTOs is the terrain and global sensors. 
These PROTOS are unvarying and provide global information for the entire world. 
Aircraft and target PROTO instantiations compile the third part of the virtual world. 
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Each instantiation contains information to identify each object. The final section consists 
of the ROUTE that plugs the global timeserver clock into each aircraft instance to drive 
the animation process. The last two sections show renderings of various different XML 
air plans. Figure 7.2 shows the structure of the virtual air plan with associated example 
code. 



EXTERNPROTO 

Declarations 



Terrain PROTO & 
Global Sensors 




Aircraft & Target 
Instantiations 



ROUTES 
(Master Clock) 

i 




EXTERNPROTO geoOrigin I 

axposedField MFString geoSystem 
exposedField SFString geoCoords 
field SFBool rotateYUp] 
[ "QeoVRML\geoOrigin.wri"! 



Terrain { geoOrigin USE AirPlan_Origin) 
DEF Global_Control Control! 

cycle Interval 600 



DEF Ghost_Rider 

Aircraft {geoOrigin USE AirPlan_Origin 
geoSystem [ "UTM" , "Zll"3 
Aircraf tType [ F-15 {)] 
CallSign "Ghost_Rider* 

Mission "Total Destruction* 
Takeoff Position 

"4040500 536500 0* 
WayPointTime 

(0.0 0.231 0.550 0.85661 
WayPornts 

("4040500 536500 0* — 3 } 

ROUTE 

Globa l_Control . fraction_changed 
TO 

Gbost_Rider. set_fraction 



Figure 7.2. Virtual Air Plan Structure 
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C. AIRCRAFT PROTO 



In order to simplify rendering of aircraft in the virtual world, a single Aircraft 
PROTO was developed. The Aircraft PROTO is responsible for accessing the aircraft 
model and flying behavior libraries. Since all aircraft behave in a similar fashion, the 
Aircraft PROTO offers a convenient interface between the virtual world and the library 
functions. The Aircraft PROTO receives data from the virtual air plan, calls up the 
aircraft specified, and flies it from waypoint to waypoint. The Aircraft PROTO 
maintains the characteristic information about each aircraft (such as Call Sign), and 
passes the data onto the Heads-Up Display (HUD). 

The Aircraft PROTO file is comprised of EXTERNPROTO declarations, node 
interface, main PROTO body, HUD and ROUTES. The EXTERNPROTO declarations 
reference the aircraft model library and a larger set of Geo VRML functions. The 
declarations are not actually contained inside the Aircraft PROTO definition but are 
enumerated at the top of the file. 

The first section of the Aircraft PROTO definition is the node interface. This 
interface defines the data that is passed into and out of the PROTO. The data passed into 
each instantiation PROTO must exactly match the same field names and data types 
described in the original interfaces. This allows the PROTO to strictly control the flow of 
information without error. 

The main body of the VRML scene performs the actual work of flying the 
aircraft. The GeoLocation node is used in conjunction with the GeoPositionlnterpolator 
node to animate the flying of an aircraft. The GeoLocation node places the aircraft at the 
data point given in the TakeoffPosition field of the node interface. The 
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GeoPositionlnterpolator node then calculates the aircraft’s position based on the waypoint 
location and waypoint arrival time. The new position is routed into the GeoLocation 
node to actuate the aircraft movement. 

Next, the Aircraft PROTO instantiates the HeadsUpDisplay PROTO. Data from 
the virtual air plan, such as Mission Type, is copied into the HUD interface. The display 
only appears when a viewer places a pointer over the aircraft. This is accomplished 
through the use of a GeoTouchSensor. 

The last section contains the ROUTE nodes. The master clock from the virtual 
world connects to the GeoPositionlnterpolator to drive the animation process. The 
GeoPositionlnterpolator sends position values into the GeoLocation node to move the 
aircraft. The GeoTouchSensor couples up with the HeadsUpDisplay node to turn the 
display on and off. Figure 7.3 shows an AH-64 Apache with the HUD displayed. Figure 
7.4 illustrates the Aircraft PROTO sections and associated VRML code. The arrows 
depict the ROUTEs connecting each of the nodes. 
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Figure 7.3. Flying Behind an AH-64 Apache with HUD Displayed. 
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PROTO Aircraft [ 



field 


SFNode 


geoOrigin NULL 


field 


MFString 


geoSystem [ "UTM" ] 


field 


MFNode 


AircraftType [ ] 


field 


SFString 


CallSign "NoSign" 


field 


SFString 


Mission "NoMission" 


field 


SFString 


MissionNumber "NoNumber" 


field 


SFString 


Takeoff Position ntv 


field 


MFString 


WayPoints [ nn ] 


field 


MFFloat 


WayPointTime [ ] 


eventln 


SFFloat 


set_fraction 



{ # - - BEGIN Aircraft PROTO 

Group { 

children [ 

DEF GeoTouch GeoTouchSensor { 

geoOrigin IS geoOrigin 
geoSystem IS geoSystem > 



DEF GeoPosInt GeoPositionlnterpolator { 



geoOrigin 

geoSystem 

key 

keyValue 



IS geoOrigin 
IS geoSystem 
IS WayPointTime 
IS Waypoints 



DEF GeoPos 



>4 

iS 

m 



in 

O 

S- C 



set_fraction IS set_fraction} 

GeoLocation { 

geoOrigin IS geoOrigin 
geoSystem IS geoSystem 
geoCoords IS Takeoff Position 
children IS AircraftType > 



DEF HUD Display { 

CallSign IS Callsign 

Mission IS Mission 

MissionNumber IS MissionNumber 

Takeoff Posit ion IS Takeoff Position 

># — HUD 

] > 



ROUTE GeoTouch. isOver TO HUD. turnOn 
ROUTE GeoPosInt . geo value_changed TO 

GeoPos . set_geoCoords 
ROUTE GeoPos . geoCoords_changed TO 

HUD. set__geoCoords 

} # END Aircraft PROTO 



Figure 7.4. Aircraft PROTO with ROUTE wiring for event 
passing 
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D. 



AIRCRAFT MODEL CONTROL PROTO 



The Aircraft Model Control PROTO is responsible for organizing all the models 
of a specific type of aircraft into one easy accessible node. The PROTO controls the 
level of detail to be displayed in the virtual battlespace. A low-detail model is displayed 
in the high Viewpoints, and progressively higher detail models are displayed as the 
Viewpoints move progressively closer to the aircraft. Mobile Viewpoints that remain 
attached relative to the aircraft are also established in this PROTO. An example PROTO 
is the F-15 PROTO shown in Figure 7.5. This PROTO calls on the various models 
displayed in Figure 7.6. 



{ 

-c 



Viewpoints 
(Move w/ Aircraft) 



EXTERNPROTO 

Declaration 



Node Interface 



Level of Detail 



r 



< 






EXTERNPROTO F-15_High [ 1 

£"F-15JEUgh.wrl#F-15_JIigh"] 

EXTERNPROTO F-15_Medium [ 3 

[ " F - 1 SJMedium. wr 1#F- 1 5_Medium" ] 

EXTERNPROTO F-15„Low [ ] 

[ "F-15_LrOw.v?xl#F- 15_LrOw"] 

PROTO F-15 [ 

field SFString Top_De script ion M F~15_PROTO"] 

j 

{#- -Begin F-15 

Group ( 
children £ 

Viewpoint: {description IS Top_De script ion 
position 500.0 50000.0 0.0 
orientation 1.0 0.0 0.0 -1.57 }, 

Viewpoint {description "Directly OverHead" 
position 15.0 500.0 0.0 
orientation 1.0 0-0 0.0 -1.57 }, 

Viewpoint {description "Ride On Back" 
position 3800 2000 0 
orientation -0.30 0.91 0.30 1.67 } 

Transform { 

children £ 

LOD { 

range £ 10000,100000] 
level £F-15_High {> , 

F-15„Medium {} , 

F-15„Low {} 1 ># End LOD 

] > 1 > 

}# END F-15 



Figure 7.5. F-15 PROTO 
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Figure 7 6. Two Different F-15 Level of Detail Models Provide by F-15 PROTO 
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E. TARGET PROTO 



The Target PROTO is similar to Aircraft PROTO. Since the targets are not 
moving, they only need to be placed at a given location. The structure of the Target 
PROTO remains the same except that the HUD and the ROUTES are not needed. Figure 
7.6 illustrates the target PROTO. 




EXTERNPROTO GeoLocation [ 

field SFNode 

field MFString 
field SFString 

field MFNode 
event In SFString 
eventOut SFString 
[ "GeoLocation .wrl " 



geoOrigin 
geoSystem 
geoCoords 
children 
set_geoCoords 
geoCoords ^changed] 
] 



PROTO Target [ 



field 


SFNode 


field 


MFString 


field 


MFNode 


field 


SFString 


field 


SFString 


BEGIN Target 


PROTO 



geoOrigin NULL 
geoSystem ["UTM"] 
TargetType [ ] 
Callsign "NoSign" 
TargetPosition[ ""] 



Group { 

children [ 

DEF GeoPos GeoLocation { 

geoOrigin IS geoOrigin 
geoSystem IS geoSystem 
geoCoords IS TargetPosition 
children IS Aircraf tType) 



> 

} #- -END Target PROTO 



Figure 7.7. Target PROTO 



F. TERRAIN PROTO 

The last major PROTO called by the virtual-battlespace air plan is the Terrain 
PROTO. This PROTO is composed of two sections in the main body. The first section 
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defines the GeoViewpoint nodes, which are used to demarcate absolute Viewpoints 
above and within the virtual battlespace. Unlike the viewpoints found in the F-15 
PROTO, these GeoViewpoints remain fixed within the Geo Coordinate system and offers 
context to a specific location the virtual environment. Figure 7.8 and 7.9 presents four 
different GeoViewPoints. 

The terrain’s geometry encompasses the second section of the PROTO and is 
adapted from work done by the DIS-java-VRML working group. A set of Elevation 
Grids based on data collected on Fort Irwin terrain is the foundation of this geometry. 

The Elevation Grid is wrapped in a texture map of satellite imagery for the Fort Irwin 
terrain. The terrain is then georeferenced to the Fort Irwin coordinates within the virtual 
world. The effect is a contoured landscape that looks remarkably real and provides an 
excellent backdrop for low-flying missions. 
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Figure 7.8. Two GeoReferenced Viewpoints. 
Red Domes Indicate Target Footprints 
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Figure 7.9. Two GeoViewpoints of the Battlespace 
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Figure 7.10 A Low Flying Apache Set Against Ft. Irwin Terrain 
G. SUMMARY 

This chapter describes how the virtual-battlespace air plan is implemented using 
VRML for animated 3D graphics. PROTOs allow the virtual air plan to remain 
uncomplicated and scalable, facilitating the autogeneration process. The three main 
PROTOs (Aircraft, Target, and Terrain) act both as a content-creation tool and as an 
interface between the virtual air plan and the detailed PROTO libraries. This modular 
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code structure allows for easy maintainabilty and reusablity. The XSL stylesheet 
generating the VRML code from the XML ATO is able to remain generic and only has to 
produce interface code for each aircraft and target. The end result is a visually appealling 
virtual-battlespace that can display the dynamic behavior of any permutation of an XML 
ATO. 
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VIII. DEMONSTRATION RESULTS AND LIMITATIONS 



A. INTRODUCTION 

An air plan can be successfully rendered in a virtual world from an XML 
structured ATO. This chapter outlines the result of the ATO to virtual world proof of 
concept and states the results in qualitative terms. Additionally, limitations of the XML 
ATO model and virtual air plan PROTO suite are delineated in this chapter. 



B. AIR TASKING ORDER MODEL RESULTS 

The proof-of-concept ATO data conversion model created in XML is successfully 
implemented. This conclusion is based on the following: 

1. Each XML document passes through the Saxon parser and the Microsoft 
XML parser. 

2. Each XML document generated through a stylesheet transformation 
reflects the expected data results and formats. 

3. The unit identification HTML file successfully finds all units specified 
within the ATO. Additionally, a similar stylesheet can be successfully 
applied to a well-formed (though not formally valid) “real world” XML 
ATO from the Desert Storm Operation. 

4. The VRML code produced from the Master Operation Document (MOD) 
successfully passes the Vorlon (http://www.trapezium.com/vorlon.html) 
VRML conformance and syntax checker. 



C. XML MODEL LIMITATIONS 

1. Air Tasking Order DTD Redundancies 

The Air Tasking Order DTD developed by the XML-MTF Development Team is 
the basis for all data structures used within this thesis. This was done to remain in 
compliance with the XML-MTF standard. However, the XML-MTF Air Tasking Order 
DTD is highly redundant and goes against the XML goals of simplicity and human 
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readability. A prime example of this redundancy is route point positional data. As seen 
in Figure 8.1, there are 16 different ways to describe a single route point location. Such 
an approach is prone to errors. 

Several improvements are immediately possible. All the geodetic latitude- 
longitude positions and Universal Transverse Mercator (UTM) coordinates can be 
combined into one type of detailed element. Algorithms already exist that translate 
between UTM and latitude-longitude positions. These algorithms can be implemented 
via stylesheets and eliminate nine of the redundancies. 

Three more redundancies are eliminated if the route_point_abbrev_georef 
elements are deleted and a new element encompasses the data in both 

route_point_georef_minutes and route_point_georef_centiminute. Taking these 
steps reduces the number of elements describing a single route point by a factor of four. 

Reduction of the ATO redundancies not only increases the simplicity and 
readability of the ATO’s structure, it also reduces the size and developmental times of 
XSL stylesheets. In Figure 8.1, a stylesheet must be created with the ability to parse 
through the data in each of the 16 children listed. What is not shown in Figure 8.1 is that 
14 of the 16 children have numerous children of their own and the stylesheet must 
accommodate those elements as well. For example, if a fuel consumption calculation is 
desired, the stylesheet needs to accommodate every route point type and becomes 
unwieldy. Such efficiencies reduce document size, avoid numerous error modes, and 
also improve processing time, compression and transmission times. 
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< ! ELEMENT route_point_route ( 

r ou t e_p o i n t _name 

route_point_lat_long_degrees 

route_point_lat_long_minutes 

route_point_lat_long_seconds 

route_point_verif ied_lat_long_degrees | 

route_point_verif ied_lat_long_minutes 

route_point_verif ied_lat_long_seconds 

route_point_utm_1000_meter | 

route_point_utm_100_meter 

route_point_utm_10_meter 

route_point_utm_l_meter 

route_point_georef_minute 

route_point_georef_centiminute 

route_point_abbrev_georef_minutes 

route_point_abbrev_georef_centiminute 

r ou t e_po in t_bear i ng_di s tanc e_f r om_re f _p t_expanded 

icao_base_code 

)? > 

Figure 8.1. Example of ATO DTD Redundancies in Current Version of 

XML-MTF 



2. Simplified Air Tasking Order (SATO) DTD Structure 

The simplified ATO (SATO) DTD used in this thesis is not all encompassing. 

The SATO DTD is only capable of handling and transforming data describing air attack 
missions. No support missions, such as air-to-air refueling, are supported. This was a 
conscious decision made to reduce the complexity of ATO data and the complexity of the 
virtual world. Nevertheless it is a fully representative example demonstrating all 
necessary aspects of the XML/XSL/VRML methodology presented here. 

3. W3C XML Specification Draft Status 

Currently the XML specification is well developed and robust; however, related 
parts of the specification are still in draft form and many pieces are still being designed 
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(e.g. XLinks). Additionally, no web browser is 100% compliant with the completed 
portions of the XML specification. As a result, these two deficiencies pose limitations on 
the design of the demonstration. For example, the initial design of the XML model called 
for users to navigate through the entire demonstration within a browser environment. 
Instead, an awkward command line environment is employed for one-time ATO 
conversion. 

4. Waypoint Arrival Times 

In order to move aircraft around a virtual world, both waypoint locations and 
waypoint arrival times must be transferred from the Master Operational Document 
(MOD) to the VRML source code. Since waypoint data is outside the scope of the XML- 
MTF Air Tasking Order DTD, this thesis creates a single data structure that is simple to 
manipulate. In this thesis, the choice of temporal units of data structure for waypoint 
arrival times is cumulative seconds from the start time of the ATO. This decision is 
based on the virtual air plan’s need for a cumulative measure of time normalized between 
zero and one. Other variations are possible but reliable consistency remains paramount. 

For clarity, an example of normalized cumulative time follows. If a plane is 
scheduled to takeoff one hour after the effective start time of the ATO and the ATO is 24 
hours long (or 86,400 seconds long), then the takeoff time is 0.041666667 
([1 hr * 60 minutes/hr * 60 seconds/minute] / 86,400 seconds). 

In retrospect, a better representation might be to annotate times in terms of 
months, days, hours, minutes, seconds, and time zone. This structure has greater 
flexibility and can be converted into normalized times. To do so, a set of XSL variables 
can be created to compute the effective start time of the ATO and the total time of the 
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ATO. The cumulative time for each waypoint is calculated from the ATO’s start time 
and then normalized based on the total time of the ATO. The normalized time can then 
be passed onto the VRML code by a stylesheet. Sophisticated yet straightforward 
arithmetic and logic programming examples can be found in the Instant Saxon 
documentation (Kay, 2000) and the XSLT Programmer’s Reference (Kay, 2000). 

D. VRML MODEL RESULTS 

The Virtual Reality Modeling Language and the Geo VRML set of PROTOs 
provide a capable methodology for building virtual environments using compact 
autogenerated code. The VRML air-plan PROTO suite successfully displays multiple 
variations of the autogenerated virtual air plan. Each object designated in the XML ATO 
is correctly rendered and georeferenced. Additionally the virtual aircraft successfully fly 
between all given waypoints and maintain individual contextual information. 

E. VRML LEARNING CURVE 

The basic concepts of the Virtual Reality Modeling Language can be learned in 
approximately 10 weeks. Nevertheless, becoming efficient at developing user-friendly 
virtual environments can take several months of (often trial-and-error) coding practice. A 
substantial amount of time is spent on engineering the user interface to provide the 
meaningful viewpoints and useful user interactions. 

Although on the surface VRML looks like any other programming language, it is 
considerably different. The concept of developing scene graph content, rather than 
program code, is a significant paradigm shift and there are many conceptual insights to 
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attain. For instance, the interface used to pass variables to PROTO nodes is clumsy and 
the movement of data via ROUTES can be awkward. Nevertheless, a primary advantage 
of VRML is that scene graph content is not plagued by code-maintenance and platform 
portability problems like other programming languages. 

F. VRML MODEL LIMITATIONS 

The major limitation to the air plan PROTO suite is that the XSL stylesheet must 
contain an EXTERNPROTO reference to all aircraft and target models that need to be 
rendered. It is preferable that autogenerated code remains flexible enough to take 
advantage of future model updates, only being changed when major modifications are 
made to the interfaces of the three main PROTOs. Currently, the model cannot handle 
aircraft and targets that are not predefined in the stylesheet. Model libraries are an 
important area for future work. 

Although the PROTO library limits the allowed number of aircraft and target 
model definitions, new model definitions are straightforward to add. If the VRML code 
defining a model’s structure is previously generated, the air plan PROTO library can be 
updated within a couple of hours. If the model is not readily available, then it takes one 
to seven days, based on the level of detail desired, to construct a structural model. Target 
models that simulate physical attributes (such as a radar’s probability of detection) can 
take up to several weeks (or months) to fully develop. Integration of 3D renderings with 
physically-based models and interactive network protocols remains the objective in most 
cases. 
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o. 



SUMMARY 



This chapter reviews the results of the ATO to virtual world proof of concept. 

The XML ATO and VRML air plan models successfully render a 3D virtual air plan and 
have the potential to be scaled to a "real world" ATO. However, many limitations exist 
within the ATO and VRML air plan models. Most notably, the XML specification is still 
in a draft status. Consequently, many XML features, such as XSchema and XLink, are 
either not fully developed or not supported by commercially available XML products. 

The current structure of the SATO does not satisfy all the tasks specified in the ATO (i.e.. 
Tomahawk missions and reconnaissance missions). Additionally, many redundancies 
contained in the XML-MTF ATO provide a laborious atmosphere that will hinder further 
development of a virtual battlespace for the rendering of a complete ATO. The VRML 
model is limited to aircraft found in the predefined libraries. Developing virtual worlds 
with VRML is straightforward to learn but takes a significant amount of time and practice 
to become proficient at building meaningful interfaces. 
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IX. CONCLUSIONS AND RECOMMENDATIONS FOR FURTHER WORK 



A. CONCLUSION 

The automatic transformation of an Air Tasking Order (ATO) into a 3D virtual 
world capable of displaying air attack missions is possible. Using the power of XML as 
the backbone of the ATO’s data structures, an ATO can easily be manipulated, 
transformed, modularized, and reconstituted into other documents. Additionally, XML’s 
formatting capabilities easily allow the creation of VRML source code. The Virtual 
Reality Model Language and the new GeoVRML Recommended Practice, provide a 
convenient environment to author, deploy and render such 3D virtual worlds. 

B. RECOMMENDATIONS FOR FUTURE WORK 

1. Reduction of Redundancies in the Air Tasking Order DTD 

The XML-MTF Development team has developed a software tool that auto- 
generates DTDs for USMTF messages. While this is a useful technique which may work 
well for small and simple messages, it does pose some problems when dealing with long 
and complex messages like the ATO. Autogeneration of DTD design carries over many 
redundancies that have grown through the long history of the USMTF format. The end 
result is a complex DTD design that is neither simple to use nor human readable. 

It is recommended that a small team of people knowledgeable in both the tactical 
needs of message consumers and the engineering of DTD design are brought together to 
further simplify the draft XML-MTF/ ATO message standard and create a simpler DTD 
tagset for the ATO. 
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